+ All Categories
Home > Documents > Smith Nair

Smith Nair

Date post: 13-Apr-2015
Category:
Upload: boopathi-shanmugam
View: 55 times
Download: 2 times
Share this document with a friend
Description:
virtual machines itroduction
7
0018-9162/05/$20.00 © 2005 IEEE 32 Computer COVER FEATURE Published by the IEEE Computer Society The Architecture of Virtual Machines V irtualization has become an important tool in computer system design, and vir- tual machines are used in a number of subdisciplines ranging from operating systems to programming languages to processor architectures. By freeing developers and users from traditional interface and resource con- straints, VMs enhance software interoperability, system impregnability, and platform versatility. Because VMs are the product of diverse groups with different goals, however, there has been rela- tively little unification of VM concepts. Consequently, it is useful to take a step back, con- sider the variety of VM architectures, and describe them in a unified way, putting both the notion of virtualization and the types of VMs in perspective. ABSTRACTION AND VIRTUALIZATION Despite their incredible complexity, computer sys- tems exist and continue to evolve because they are designed as hierarchies with well-defined interfaces that separate levels of abstraction. Using well- defined interfaces facilitates independent subsystem development by both hardware and software design teams. The simplifying abstractions hide lower-level implementation details, thereby reducing the com- plexity of the design process. Figure 1a shows an example of abstraction applied to disk storage. The operating system abstracts hard-disk addressing details—for exam- ple, that it is comprised of sectors and tracks—so that the disk appears to application software as a set of variable-sized files. Application programmers can then create, write, and read files without know- ing the hard disk’s construction and physical orga- nization. A computer’s instruction set architecture (ISA) clearly exemplifies the advantages of well-defined interfaces. Well-defined interfaces permit develop- ment of interacting computer subsystems not only in different organizations but also at different times, sometimes years apart. For example, Intel and AMD designers develop microprocessors that implement the Intel IA-32 (x86) instruction set, while Microsoft developers write software that is compiled to the same instruction set. Because both groups satisfy the ISA specification, the software can be expected to execute correctly on any PC built with an IA-32 microprocessor. Unfortunately, well-defined interfaces also have their limitations. Subsystems and components designed to specifications for one interface will not work with those designed for another. For exam- ple, application programs, when distributed as com- piled binaries, are tied to a specific ISA and depend on a specific operating system interface. This lack of interoperability can be confining, especially in a world of networked computers where it is advan- tageous to move software as freely as data. Virtualization provides a way of getting around such constraints. Virtualizing a system or compo- nent—such as a processor, memory, or an I/O device—at a given abstraction level maps its inter- face and visible resources onto the interface and resources of an underlying, possibly different, real system. Consequently, the real system appears as a different virtual system or even as multiple virtual systems. Unlike abstraction, virtualization does not nec- essarily aim to simplify or hide details. For example, in Figure 1b, virtualization transforms a single large disk into two smaller virtual disks, each of which A virtual machine can support individual processes or a complete system depending on the abstraction level where virtualization occurs. Some VMs support flexible hardware usage and software isolation, while others translate from one instruction set to another. James E. Smith University of Wisconsin-Madison Ravi Nair IBM T.J. Watson Research Center
Transcript
Page 1: Smith Nair

0018-9162/05/$20.00 © 2005 IEEE32 Computer

C O V E R F E A T U R E

P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

The Architecture ofVirtual Machines

V irtualization has become an importanttool in computer system design, and vir-tual machines are used in a number ofsubdisciplines ranging from operatingsystems to programming languages to

processor architectures. By freeing developers andusers from traditional interface and resource con-straints, VMs enhance software interoperability,system impregnability, and platform versatility.

Because VMs are the product of diverse groupswith different goals, however, there has been rela-tively little unification of VM concepts.Consequently, it is useful to take a step back, con-sider the variety of VM architectures, and describethem in a unified way, putting both the notion ofvirtualization and the types of VMs in perspective.

ABSTRACTION AND VIRTUALIZATIONDespite their incredible complexity, computer sys-

tems exist and continue to evolve because they aredesigned as hierarchies with well-defined interfacesthat separate levels of abstraction. Using well-defined interfaces facilitates independent subsystemdevelopment by both hardware and software designteams. The simplifying abstractions hide lower-levelimplementation details, thereby reducing the com-plexity of the design process.

Figure 1a shows an example of abstractionapplied to disk storage. The operating systemabstracts hard-disk addressing details—for exam-ple, that it is comprised of sectors and tracks—sothat the disk appears to application software as aset of variable-sized files. Application programmerscan then create, write, and read files without know-ing the hard disk’s construction and physical orga-nization.

A computer’s instruction set architecture (ISA)clearly exemplifies the advantages of well-definedinterfaces. Well-defined interfaces permit develop-ment of interacting computer subsystems not onlyin different organizations but also at different times,sometimes years apart. For example, Intel andAMD designers develop microprocessors thatimplement the Intel IA-32 (x86) instruction set,while Microsoft developers write software that iscompiled to the same instruction set. Because bothgroups satisfy the ISA specification, the softwarecan be expected to execute correctly on any PC builtwith an IA-32 microprocessor.

Unfortunately, well-defined interfaces also havetheir limitations. Subsystems and componentsdesigned to specifications for one interface will notwork with those designed for another. For exam-ple, application programs, when distributed as com-piled binaries, are tied to a specific ISA and dependon a specific operating system interface. This lack ofinteroperability can be confining, especially in aworld of networked computers where it is advan-tageous to move software as freely as data.

Virtualization provides a way of getting aroundsuch constraints. Virtualizing a system or compo-nent—such as a processor, memory, or an I/Odevice—at a given abstraction level maps its inter-face and visible resources onto the interface andresources of an underlying, possibly different, realsystem. Consequently, the real system appears as adifferent virtual system or even as multiple virtualsystems.

Unlike abstraction, virtualization does not nec-essarily aim to simplify or hide details. For example,in Figure 1b, virtualization transforms a single largedisk into two smaller virtual disks, each of which

A virtual machine can support individual processes or a complete systemdepending on the abstraction level where virtualization occurs. Some VMssupport flexible hardware usage and software isolation, while others translate from one instruction set to another.

James E.SmithUniversity ofWisconsin-Madison

Ravi NairIBM T.J. WatsonResearch Center

Page 2: Smith Nair

appears to have its own tracks and sectors.Virtualizing software uses the file abstraction as anintermediate step to provide a mapping betweenthe virtual and real disks. A write to a virtual diskis converted to a file write (and therefore to a realdisk write). Note that the level of detail provided atthe virtual disk interface—the sector/track address-ing—is no different from that for a real disk; noabstraction takes place.

VIRTUAL MACHINESThe concept of virtualization can be applied not

only to subsystems such as disks but to an entiremachine. To implement a virtual machine, devel-opers add a software layer to a real machine to sup-port the desired architecture. By doing so, a VMcan circumvent real machine compatibility andhardware resource constraints.

Architected interfacesA discussion of VMs is also a discussion about

computer architecture in the pure sense of the term.Because VM implementations lie at architectedinterfaces, a major consideration in the construc-tion of a VM is the fidelity with which it imple-ments these interfaces.

Architecture, as applied to computer systems,refers to a formal specification of an interface in thesystem, including the logical behavior of resourcesmanaged via the interface. Implementationdescribes the actual embodiment of an architecture.Abstraction levels correspond to implementationlayers, whether in hardware or software, each asso-ciated with its own interface or architecture.

Figure 2 shows some important interfaces andimplementation layers in a typical computer sys-tem. Three of these interfaces at or near theHW/SW boundary—the instruction set architec-ture, the application binary interface, and the appli-cation programming interface—are especiallyimportant for VM construction.

Instruction set architecture. The ISA marks thedivision between hardware and software, and con-sists of interfaces 3 and 4 in Figure 2. Interface 4represents the user ISA and includes those aspectsvisible to an application program. Interface 3, thesystem ISA, is a superset of the user ISA andincludes those aspects visible only to operating sys-tem software responsible for managing hardwareresources.

Application binary interface. The ABI gives a pro-gram access to the hardware resources and servicesavailable in a system through the user ISA (inter-face 4) and the system call interface (interface 2).

The ABI does not include system instructions;rather, all application programs interact with thehardware resources indirectly by invoking theoperating system’s services via the system call inter-face. System calls provide a way for an operatingsystem to perform operations on behalf of a userprogram after validating their authenticity andsafety.

Application programming interface. The API gives aprogram access to the hardware resources and ser-vices available in a system through the user ISA(interface 4) supplemented with high-level language

May 2005 33

(b)(a)

File File

File File

Abstraction Virtualization

Figure 1. Abstraction and virtualization applied to disk storage. (a) Abstractionprovides a simplified interface to underlying resources. (b) Virtualization providesa different interface or different resources at the same abstraction level.

Hardware

Software

Memorytranslation

API

ABIISA

Mainmemory

I/O devicesand

networking

Applicationprograms

Libraries

Operating system

Execution hardware

System interconnect(bus)

1

2

3 4

Figure 2. Computer system architecture. Key implementation layers communicatevertically via the instruction set architecture (ISA), application binary interface(ABI), and application programming interface (API).

Page 3: Smith Nair

34 Computer

(HLL) library calls (interface 1). Any system callsare usually performed through libraries. Using anAPI enables application software to be ported eas-ily, through recompilation, to other systems thatsupport the same API.

Process and system VMs To understand what a virtual machine is, it is first

necessary to consider the meaning of “machine”from both a process and system perspective.

From the perspective of a process executing a userprogram, the machine consists of a logical memoryaddress space assigned to the process along withuser-level instructions and registers that allow theexecution of code belonging to the process. Themachine’s I/O is visible only through the operatingsystem, and the only way the process can interactwith the I/O system is through operating systemcalls. Thus the ABI defines the machine as seen by aprocess. Similarly, the API specifies the machine char-acteristics as seen by an application’s HLL program.

From the perspective of the operating system andthe applications it supports, the entire system runs onan underlying machine. A system is a full executionenvironment that can support numerous processessimultaneously. These processes share a file systemand other I/O resources. The system environmentpersists over time as processes come and go. The sys-tem allocates real memory and I/O resources to theprocesses, and allows the processes to interact withtheir resources. From the system perspective, there-fore, the underlying hardware’s characteristics alonedefine the machine; it is the ISA that provides theinterface between the system and machine.

Just as there are process and system perspectivesof “machine,” there are process and system virtualmachines. A process VM is a virtual platform thatexecutes an individual process. This type of VMexists solely to support the process; it is createdwhen the process is created and terminates whenthe process terminates. In contrast, a system VMprovides a complete, persistent system environmentthat supports an operating system along with itsmany user processes. It provides the guest operat-ing system with access to virtual hardwareresources, including networking, I/O, and perhapsa graphical user interface along with a processorand memory.

The process or system that runs on a VM is theguest, while the underlying platform that supportsthe VM is the host. The virtualizing software thatimplements a process VM is often termed the run-time, short for “runtime software.” The virtualiz-ing software in a system VM is typically referredto as the virtual machine monitor (VMM).

Figure 3 depicts process and system VMs, withcompatible interfaces illustrated graphically asmeshing boundaries. In a process VM, the virtual-izing software is at the ABI or API level, atop theOS/HW combination. The runtime emulates bothuser-level instructions and either operating systemor library calls. In a system VM, the virtualizingsoftware is between the host hardware machineand the guest software. The VMM emulates thehardware ISA so that the guest software can poten-tially execute a different ISA from the one imple-mented on the host. However, in many system VMapplications, the VMM does not perform instruc-tion emulation; rather, its primary role is to pro-vide virtualized hardware resources.

PROCESS VIRTUAL MACHINESProcess VMs provide a virtual ABI or API envi-

ronment for user applications. In their variousimplementations, process VMs offer replication,emulation, and optimization.

Multiprogrammed systemsThe most common process VM is so ubiquitous

that few regard it as being a VM. Most operatingsystems can simultaneously support multiple userprocesses through multiprogramming, which giveseach process the illusion of having a completemachine to itself. Each process has its own addressspace, registers, and file structure. The operatingsystem time-shares the hardware and managesunderlying resources to make this possible. Ineffect, the operating system provides a replicated

(b)

(a)

Application process Application process

Applications Applications

Processvirtual

machine

Virtualizing software

Virtualizing software

Guest

Runtime

Host

Guest

VMM

Host

OS OS

Hardware

Systemvirtual

machine

Hardware

OS

Figure 3. Process and system VMs. (a) In a process VM, virtualizing softwaretranslates a set of OS and user-level instructions composing one platform tothose of another. (b) In a system VM, virtualizing software translates the ISA usedby one hardware platform to that of another.

Page 4: Smith Nair

process-level VM for each of the concurrently exe-cuting applications.

Emulators and dynamic binary translatorsA more challenging problem for process-level

VMs is that of supporting program binaries com-piled to an instruction set different from the one thehost executes. A recent example of a process VM isthe Intel IA32-EL,1 which allows Intel IA-32 appli-cation binaries to run on Itanium hardware.

The most straightforward way of performingemulation is through interpretation. An interpreterprogram fetches, decodes, and emulates the execu-tion of individual guest instructions. This can be arelatively slow process, requiring tens of hostinstructions for each source instruction interpreted.Better performance can be obtained throughdynamic binary translation, which converts guestinstructions to host instructions in blocks ratherthan instruction by instruction and saves them forreuse in a software cache. Repeated execution ofthe translated instructions thus amortizes the rela-tively high overhead of translation.

Same-ISA binary optimizersTo reduce performance losses, dynamic binary

translators sometimes perform code optimizationsduring translation. This capability leads naturallyto VMs wherein the instruction sets that the hostand guest use are the same, with optimization of aprogram binary as the VM’s sole purpose. Same-ISA dynamic binary optimizers use profile infor-mation collected during the interpretation ortranslation phase to optimize the binary on-the-fly.An example of such an optimizer is the Dynamosystem, originally developed as a research project atHewlett-Packard.2

High-level-language VMsFor process VMs, cross-platform portability is

clearly a key objective. However, emulating oneconventional architecture on another providescross-platform compatibility only on a case-by-casebasis and requires considerable programming effort.Full cross-platform portability is more readilyachieved by designing a process-level VM as part ofan overall HLL application development environ-ment. The resulting HLL VM does not directly cor-respond to any real platform; rather, it is designedfor ease of portability and to match the features ofa given HLL or set of HLLs.

Figure 4 shows the difference between a con-ventional platform-specific compilation environ-ment and an HLL VM environment. In a

conventional system, shown in Figure 4a, a com-piler front end first generates intermediate code thatis similar to machine code but more abstract. Then,a code generator uses the intermediate code to gen-erate a binary containing machine code for a spe-cific ISA and operating system. This binary file isdistributed and executed on platforms that supportthe given ISA/OS combination.

In an HLL VM, as shown in Figure 4b, a com-piler front end generates abstract machine code ina virtual ISA that specifies the VM’s interface. Thisvirtual ISA code, along with associated data struc-ture information (metadata), is distributed for exe-cution on different platforms. Each host platformimplements a VM capable of loading and executingthe virtual ISA and a set of library routines specifiedby a standardized API. In its simplest form, the VMcontains an interpreter. More sophisticated, higher-performance VMs compile the abstract machinecode into host machine code for direct executionon the host platform.

An advantage of an HLL VM is that applicationsoftware is easily ported once the VM and librariesare implemented on a host platform. While the VMimplementation takes some effort, it is much sim-pler than developing a full-blown compiler for aplatform and porting every application throughrecompilation.

The Sun Microsystems Java VM architecture3

and the Microsoft Common Language Infra-structure, which is the foundation of the .NETframework,4 are widely used examples of HLLVMs. The ISAs in both systems are stack-based toeliminate register requirements and use an abstractdata specification and memory model that supportssecure object-oriented programming.

SYSTEM VIRTUAL MACHINESA system VM provides a complete environment

in which an operating system and many processes,

May 2005 35

Distribution

Distribution

HLL program

Compiler front end

Intermediate code

Compiler back end

Object code

Loader

Memory image

HLL program

Compiler

Portable code

VM loader

Virtual memory image

VM interpreter/compiler

Host instructions(b)(a)

Figure 4. High-level-language environments. (a) Conventional environment whereplatform-dependent object code is distributed. (b) HLL VM environment where aplatform-dependent VM executes portable intermediate code.

Page 5: Smith Nair

36 Computer

possibly belonging to multiple users, cancoexist. By using system VMs, a single-hosthardware platform can support multiple, iso-lated guest operating system environmentssimultaneously.

System VMs emerged during the 1960sand early 1970s5 and were the origin of theterm virtual machine. At that time, main-frame computer systems were very large,expensive, and usually shared among numer-ous users; with VM technology, different usergroups could run different operating systems

on the shared hardware. As hardware became less expensive and much of

it migrated to the desktop, interest in these origi-nal system VMs faded. Today, however, systemVMs are enjoying renewed popularity as the largemainframe systems of the past have been replacedby servers or server farms shared by many users or groups.

Perhaps the most important current applicationof system VM technology is the isolation it pro-vides between multiple systems running concur-rently on the same hardware platform. If securityon one guest system is compromised or if one guestoperating system suffers a failure, the software run-ning on other guest systems is not affected.

In a system VM, the VMM primarily providesplatform replication. The central issue is dividing aset of hardware resources among multiple guestoperating system environments—an example isdisk virtualization, as in Figure 1. The VMM hasaccess to, and manages, all the hardware resources.A guest operating system and its applicationprocesses are then managed under (hidden) controlof the VMM. When a guest operating system per-forms a privileged instruction or operation thatdirectly interacts with shared hardware resources,the VMM intercepts the operation, checks it forcorrectness, and performs it on behalf of the guest.Guest software is unaware of this behind-the-sceneswork.

Classic system VMsFrom the user perspective, most system VMs pro-

vide essentially the same functionality but differ intheir implementation details. The classic approach6

places the VMM on bare hardware and the VMs fiton top. The VMM runs in the most highly privi-leged mode, while all guest systems run withreduced privileges so that the VMM can interceptand emulate all guest operating system actions thatwould normally access or manipulate critical hard-ware resources.

Hosted VMs An alternative system VM implementation builds

virtualizing software on top of an existing host oper-ating system, resulting in a hosted VM. An advan-tage of a hosted VM is that a user installs it just likea typical application program. Further, virtualizingsoftware can rely on the host operating system toprovide device drivers and other lower-level servicesrather than on the VMM. An example of a hostedVM implementation is the VMware GSX server,7

which runs on IA-32 hardware platforms.

Whole-system VMsIn conventional system VMs, all guest and host

system software as well as application software usethe same ISA as the underlying hardware. In somesituations, however, the host and guest systems donot have a common ISA. For example, the twomost popular desktop systems today, Windows PCsand Apple PowerPC-based systems, use differentISAs (and different operating systems).

Whole-system VMs deal with this situation by vir-tualizing all software, including the operating sys-tem and applications. Because the ISAs differ, theVM must emulate both the application and operat-ing system code. An example of this type of VM isthe Virtual PC,8 in which a Windows system runs ona Macintosh platform. The VM software executesas an application program supported by the hostoperating system and uses no system ISA operations.

Multiprocessor virtualizationAn interesting form of system virtualization

occurs when the underlying host platform is a largeshared-memory multiprocessor. Here, an impor-tant objective is to partition the large system intomultiple smaller multiprocessor systems by dis-tributing the underlying hardware resources of thelarge system.

With physical partitioning,9 the physicalresources that one virtual system uses are disjointfrom those used by other virtual systems. Physicalpartitioning provides a high degree of isolation, sothat neither software problems nor hardware faultson one partition affect programs in other partitions.With logical partitioning,10 the underlying hard-ware resources are time-multiplexed between thedifferent partitions, thereby improving systemresource utilization. However, some of the bene-fits of hardware isolation are lost.

Both partitioning techniques typically use specialsoftware or firmware support based on underlyinghardware modifications specifically targeted at par-titioning.

VM technology provides isolationbetween multiplesystems runningconcurrently on

the same hardwareplatform.

Page 6: Smith Nair

Codesigned VMsFunctionality and portability are the goals of

most system VMs that are implemented on hard-ware already developed for some standard ISA. Incontrast, codesigned VMs implement new, propri-etary ISAs targeted at improving performance,power efficiency, or both. The host’s ISA may becompletely new, or it may be an extension of anexisting ISA.

A codesigned VM has no native ISA applications.Instead, the VMM appears to be part of the hard-ware implementation; its sole purpose is to emu-late the guest’s ISA. To maintain this illusion, theVMM resides in a region of memory concealedfrom all conventional software. It includes a binarytranslator that converts guest instructions into opti-mized sequences of host ISA instructions and cachesthem in the concealed memory region.

Perhaps the best-known example of a codesignedVM is the Transmeta Crusoe.11 In this processor,the underlying hardware uses a very-long instruc-tion word architecture, and the guest ISA is the IntelIA-32. The Transmeta designers focused on thepower-saving advantages of simpler VLIW hard-ware.

The IBM AS/400 (now the iSeries) also uses co-designed VM techniques.12 Unlike other codesignedVMs, the AS/400’s primary design objective is toprovide support for an object-based instruction setthat redefines the HW/SW interface in a novel fash-ion. Current AS/400 implementations are based onan extended PowerPC ISA, whereas earlier versionsused a considerably different, proprietary ISA.

VIRTUAL MACHINE TAXONOMYGiven this broad array of VMs, with different

goals and implementations, it is helpful to put themin perspective and organize the common imple-mentation issues. Figure 5 presents a simple tax-onomy of VMs, which are first divided into eitherprocess or system VMs. Within these two majorcategories, VMs can be further distinguishedaccording to whether they use the same ISA or adifferent one. The basis for this differentiation isthat ISA emulation is a dominant feature in thoseVMs that support it.

Among the process VMs that do not perform ISAemulation are multiprogrammed systems, whichmost of today’s computers already support. Alsoincluded are same-ISA dynamic binary optimizers,which employ many of the same techniques as ISAemulation.

Process VMs with different guest and host ISAsinclude dynamic translators, with the machine

interface typically defined at the ABI level, and HLLVMs with an API-level interface.

System VMs consist of classic system VMs aswell as hosted VMs that provide replicated, iso-lated system environments. The primary differencebetween classic system and hosted VMs is theVMM implementation rather than the functionthey provide to the user.

In whole-system VMs, wherein the guest andhost ISAs are different, performance is often sec-ondary to accurate functionality. When perfor-mance or power/area efficiency becomes important,as is the case with codesigned VMs, the VM imple-mentation interface may be closer to the proces-sor’s physical hardware.

M odern computer systems are complex struc-tures containing numerous closely interact-ing components in both software and

hardware. Within this universe, virtualization actsas a type of interconnection technology. Interjectingvirtualizing software between abstraction layersnear the HW/SW interface forms a virtual machinethat allows otherwise incompatible subsystems towork together. Further, replication by virtualiza-tion enables more flexible and efficient use of hard-ware resources.

VMs are now widely used to enable interoper-ability between hardware, system software, andapplication software. Given the heavy reliance onstandards and consolidation occurring in the indus-try, it is likely that any new ISA, operating system,or programming language will be based on VMtechnology. In the future, VMs should be viewedas a unified discipline to the same degree that hard-

May 2005 37

Process VMs System VMs

DifferentISA

SameISA

DifferentISA

SameISA

Multiprogrammedsystems

Dynamictranslators

Classic systemVMs

Whole-systemVMs

CodesignedVMs

HostedVMs

High-level-languageVMs

Same-ISA dynamicbinary optimizers

Figure 5. Virtual machine taxonomy. Within the general categories of processand system VMs, ISA simulation is the major basis of differentiation.

Page 7: Smith Nair

38 Computer

ware, operating systems, and application softwareare today. �

References1. L. Baraz et al., “IA-32 Execution Layer: A Two-Phase

Dynamic Translator Designed to Support IA-32Applications on Itanium-Based Systems,” Proc. 36thAnn. IEEE/ACM Int’l Symp. Microarchitecture,IEEE CS Press, 2003, pp. 191-204.

2. V. Bala, E. Duesterwald, and S. Banerjia, “Dynamo:A Transparent Dynamic Optimization System,” Proc.ACM SIGPLAN 2000 Conf. Programming Lan-guage Design and Implementation, ACM Press,2000, pp. 1-12.

3. T. Lindholm and F. Yellin, The Java Virtual MachineSpecification, 2nd ed., Addison-Wesley, 1999.

4. D. Box, Essential .NET, Volume 1: The CommonLanguage Runtime, Addison-Wesley, 2002.

5. R.J. Creasy, “The Origin of the VM/370 Time-Shar-ing System,” IBM J. Research and Development,Sept. 1981, pp. 483-490.

6. R.P. Goldberg, “Survey of Virtual MachineResearch,” Computer, June 1974, pp. 34-35.

7. J. Sugerman, G. Venkitachalam, and B-H. Lim, “Vir-tualizing I/O Devices on VMware Workstation’sHosted Virtual Machine Monitor,” Proc. GeneralTrack: 2001 Usenix Ann. Technical Conf., UsenixAssoc., 2001, pp. 1-14.

8. E. Traut, “Building the Virtual PC,” Byte, Nov. 1997,pp. 51-52.

9. Sun Microsystems, “Sun Enterprise 10000 Server:Dynamic System Domains,” tech. white paper, 1999;www.sun.com/datacenter/docs/domainswp.pdf.

10. T.L. Borden, J.P. Hennessy, and J.W. Rymarczyk,“Multiple Operating Systems on One ProcessorComplex,” IBM Systems J., Jan. 1989, pp. 104-123.

11. A. Klaiber, “The Technology Behind Crusoe Proces-sors: Low-Power x86-Compatible Processors Imple-mented with Code Morphing Software,” tech. brief,Transmeta Corp., 2000.

12. F.G. Soltis, Inside the AS/400, Duke Press, 1996.

James E. Smith is a professor in the Department ofElectrical and Computer Engineering at the Uni-versity of Wisconsin-Madison. His current researchinterests include high-performance and power-effi-cient processor implementations, processor per-formance modeling, and virtual machines. Smithreceived a PhD in computer science from the Uni-versity of Illinois. He is a member of the IEEE andthe ACM. Contact him at [email protected].

Ravi Nair is a research staff member at the IBMT.J. Watson Research Center. His current interestsinclude processor microarchitectures, dynamiccompilation, and virtual machine technology. Nairreceived a PhD in computer science from the Uni-versity of Illinois. He is a Fellow of the IEEE anda member of the IBM Academy of Technology.Contact him at [email protected].


Recommended