`cee
`i
`
`inl
`
`i a
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`a0
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`** Virtual machines have finally arrived.
`Dismissed for a number of years as
`
`merely academic curiosities, they are
`
`now seen as cost-effective techniques
`for organizing computer systems
`
`resources to provide extraordinary
`
`system flexibility and support for certain
`
`unique applications.”’
`
`
`
`
`
`oo| IX
`
`Survey of Virtual Machine Research
`
`Robert P. Goldberg
`
`Honeywell Information Systems
`and Harvard University
`
`Introduction
`
`The complete instruction-by-instruction simulation of
`one computer system on a different system is a well-known
`computing technique. It is often used for software develop-
`ment when a hardwarebaseis being altered. For example, if
`a programmer is developing software for some new special
`purpose (e.g., aerospace) computer X which is under
`construction and as yet unavailable, he will likely begin by
`writing a simulator for that computer on someavailable
`general-purpose machine G. The simulator will provide a
`detailed simulation of the special-purpose environment X,
`including its processor, memory, and I/O devices. Except
`for possible timing dependencies, programs which run on
`the “simulated machine X” can later run on the “real
`machine X”’ (whenit is finally built and checked out) with
`identical effect. The programs running on X can be
`
`34
`
`simulated I/O
`to exercise
`arbitrary — including code
`devices, move data and instructions anywhere in simulated
`memory, or execute any instruction of the simulated
`machine. The
`simulator provides a layer of software
`filtering which protects the resources of the machine G
`from being misused by programs on X.
`If several different programmers are developing software
`for X concurrently, it may be possible to run a number of
`copies of the simulator under an operating system on G.
`Alternatively,
`a
`special, more powerful version of the
`simulator may be developed which itself is a time-sharing
`system and supports multiple users. In either case,
`the
`result would be the illusion of multiple copies of the
`hardware-software interface of machine X on machine G.
`Since machines XY and G maybearbitrarily chosen, they
`maybe significantly different in structure. This may imply
`a very large simulation program and significant overhead for
`Google Exhibit 1008
`Google Exhibit 1008
`Google v. Valtrus
`Google v. Valtrus
`.
`
`

`

`the simulation of each of X’s instructions. As a result, it is
`possible to find the machine slowed down by as much as
`1000 to 1. Consequently, simulation is generally used only
`for software development and almost never in a production
`mode.
`While X and G maybe arbitrarily different, it is also
`possible to choose them to be identical — i.e., X=G. In this
`case we would be supporting many copies of the hardware-
`software interface of G on one machine G. Each user would
`have his own private copy of a machine G and could select
`the operating system of his choice to run on his “private”
`computer. He could also choose to develop or debug his
`own operating system. Asbefore, since each instruction for
`the simulated G is actually being interpreted by software on
`the real G, there can be no way for one simulated machine
`to interfere with another.
`If the real and simulated machines are identical then it
`may be possible to construct a simulator in which programs
`run with a slow-down of only about 20 to 1.* While this
`may be a considerable improvement over the more general
`simulator, it seems odd that programs being run on native
`hardware, i.e., the machines they were written for, should
`have to be slowed down at all. Considerations of this kind
`have !ed to the development of much more efficient
`simulators for multiple copies of a machine onitself.** In
`these systems, much of the software for the simulated
`machine executes directly on the hardware without soft-
`ware interpretation. Systems of this kind are called virtual
`machine systems, the simulated machinesare called virtual
`machines (VMs), and the simulator software is called the
`virtual machine monitor (VMM).
`Whether or not
`it
`is possible to construct a VMM
`depends upon the subject machine’s architecture. Even for
`systems
`in which virtual machine monitors have been
`constructed, there still remain many interesting questions
`concerning performance anduse.
`IBM’s improved virtual machine support for System/370
`(i.e., VM/370 Release 2),4°-4* the application of virtual
`machine systems to significant problems in data security/
`reliability,*°14°5!-°3 and the use of virtual machine tech-
`niques to reduce software developmentcosts'**?” are just
`some of the reasons for the widespread current interest in
`virtual machines.
`In this paper we will take up these issues in connection
`with some of the recent work on virtual machine principles,
`performance, and practice. In particular, we shall examine
`the rationale for virtual machines, discuss the implications
`of virtual machines on new architectural designs, consider
`virtual machine performance costs, and finally explore
`some of the unique applications which virtual machines
`make
`possible. The
`tutorial
`papers by Buzen and
`Gagliardi,'®*'7
`Parmelee
`et
`al,°°
`and Meyer
`and
`Seawright,°” as well as Chapters 1-3 of the author’s Ph.D.
`dissertation?* may be read for additional background
`material. Finally,
`the recent
`textbook by Madnick and
`Donovan*? includes an excellent
`introduction to virtual
`machines as part of a course on operating systems.
`
`typically oriented around the use of an
`is
`simulator
`*The
`execute-type instruction for simulating each central processor
`instruction.
`
`**Somewhat different considerations have led to the development
`of emulators which are efficient hardware or firmware assisted
`simulators for dissimilar machines. See Mallach.>?”
`
`June 1974
`
`Figure 1. Conventional Extended Machine Organization
`
`
`
`.
`
`Principles
`
`Virtual machine systems were originally developed to
`correct some of the shortcomings of the typical
`third-
`generation architectures and multi-programming operating
`systems — e.g., OS/360.?? The principal architectural char-
`acteristics of these systems was the dual-state hardware
`organization with a privileged and a non-privileged mode. In
`privileged modeall instructions are available to software,
`whereas in non-privileged mode they are not. The operating
`system provided a
`small
`resident program called the
`privileged software nucleus. User programs could execute
`the non-privileged hardware instructions or make super-
`visory calls — eg., SVCs — to the privileged software
`nucleus in order to have privileged functions — e.g., I/O —
`performed on their behalf. The set of non-privileged
`instructions together with the supervisory calls effectively
`defines an extended machine which is similar to but not
`identical to the bare machine. (See Figure 1.) The extended
`machine is, in theory, better human-engineered and easier
`to program than the original bare machine.
`The extended machine approach has been quite suc-
`cessful in many computer systemsinstallations, but there
`still are a number of problems associated with it. While
`Figure |
`illustrates multiple extended machine interfaces,
`only one bare machine interface is provided. Thus, only one
`privileged software nucleus can be run at a given time.
`Consequently,
`it
`is not possible to run other operating
`systems, certain diagnostic programs, or any software which
`requires a bare machine interface instead of an extended
`machine interface. This rigidity may have significant impact
`on the transportability of user software (written for other
`operating systems), modification and testing of the oper-
`ating system (privileged software), and the running of test
`and diagnostic (T&D) programs.
`In the face of these
`obstacles the installation’s management usually solves this
`problem with shift scheduling: operating system debugging,
`
`BARE
`BASIC
`MACHINE
`— MACHINE
`INTERFACE PRIVILEGED
`SOF TWARE
`
`NUCLEUS
`
`
` EXTENDED
`
`MACHINES
` EXTENDED
`
`USER
`PROGRAM
`
`USER
`PROGRAM
`
`MACHINE
`INTERFACE
`
`

`

`T&D, unusual or old release operating systems, and
`e CP-40 — A virtual machine system developed for a
`normal system use scheduled for separate blocks of time
`specially modified IBM 360/40,
`forerunner of
`CP-67.1>4°
`during the day (and night).
`The major innovation of virtual machines (VMs) was to
`e CP-67 — A virtual machine system developed for
`the IBM 360/67, forerunner of VM/370.° 24 57
`solve the above problem. The heart of a VM system is the
`virtual machine monitor (VMM) software which transforms
`e 360/30 — A single virtual machine supported on a
`the single machine interface into the illusion of many. Each
`specially modified IBM 360/30, used for system
`measurement.* §
`of these interfaces (virtual machines) is an efficient replica
`of the original computer system, complete with all of the
`e HITAC 8400 —Asingle virtual machine supported
`processor
`instructions
`(i.e., both privileged and non-
`on a HITAC 8400 (RCA Spectra 70/45), used for
`special software development.’ °
`privileged instructions) and system resources (i.e., memory
`and I/O devices). By running each operating system onits
`e@ UMMPS — Oneor several virtual machines (360)
`own virtual machine it becomes possible to run several
`supported concurrently with UMMPS on 360/67,
`normally used to provide OS/360 support. 41 >7°
`different operating systems (privileged software nuclei)
`concurrently. (See Figure 2.)
`e PDP-10 — A virtual machine-like system running
`Perhaps the best known virtual machine system is IBM’s
`under
`the ITS operating system on a special
`VM/370.*3>** On each virtual 370 a user may run any of
`PDP-10 at MIT.?°
`the System/360 or System/370 operating systems, such as
`Other virtual machine systems currently under devel-
`DOS/360, OS/VS1, OS/VS2, or any version of OS/360. The
`opmentinclude:
`user may also run the Conversational Monitor System
`e UCLA-VM — A virtual machine system being
`(CMS), a simple monoprogramming operating system which
`developed for specially modified PDP-11/45. Will
`was developed specifically for use on virtual machines.
`be used for data security studies.°? »°*
`Other virtual machine and virtual machine-like systems
`e Newcastle Recursive VM — Burroughs B1700 is
`which have been developed include:
`being microprogrammed to define
`a machine
`e M44/44X — A virtual machine-like system devel-
`architecture
`for which
`a VMM is_
`being
`oped for a specially modified IBM 7044.58 -6°>°7
`written.*7 48
`
`BARE
`MACHINE
`
`BASIC
`——— MACHINE
`INTERFACE
`
`
`UAL.
`
`
`
`
`
`
`
`ee—MACHINE
`PRIVILEGED
`INTERFACE
`
`
`PRIVILEGED
`SOFTWARE
`SOFTWARE
`
`NUCLEUS’
`NUCLEUS
`
`
`#2
`
`
`
`EXTENDED
`MACHINES
`
`
`
`Figure 2. Virtual Machine Organization
`
`36
`
`COMPUTER
`
`a|
`.
`
`

`

`While virtual machines, multiprogramming, and virtual
`storage are independent concepts,’'
`they form a very
`powerful construct when combined together.°° A virtual)
`machine provides an efficient,
`isolated replica of a com-
`puter
`system’s environment. With multiprogramming it
`becomes possible
`to multiplex among several virtual
`machines concurrently on a single hardware system.>°
`Finally, with virtual storage, it is possible to supportvirtual
`machines whose memory requirements exceed the actual
`resources available. °
`Despite the powerof the virtual machine concept, only a
`very limited number of virtual machine systems have
`actually been implemented. This situation is in part due to
`the
`architectural
`characteristics
`of
`third-generation
`machines which were not designed to support virtual
`machines.°°°?°®> Consequently,
`these systems do not
`provide the appropriate architectural support and force the
`existing VMMs to rely on somewhat contrived software
`techniques.
`As with the purely simulated machine discussed in the
`introduction, support of a virtual machine requires faithful
`reproduction of the processor, memory, I/O system, and
`even the operator’s console. Furthermore,
`to satisfy the
`efficiency requirements which are an essential part of the
`virtual machine concept,
`it
`is necessary to execute a
`significant portion of the virtual CPU’s instructions directly
`on the host hardware. Since the instructions to be executed
`on the virtual machine might include the privileged instruc-
`tions which can alter the mode of the machine, perform
`VO, etc., complete direct execution of software by the
`virtual machine might permit it to interfere with the VMM
`or other virtual machines. In order to prevent this situation
`from occurring it is necessary for the VMM to maintain
`proper control over the state of the real processor.
`
`Third-Generation Implementation Issues The solution
`that was adopted in third-generation architectures involved
`running all software for virtual machines in the non-
`privileged mode and having the virtual machine monitor
`maintain a virtual mode bit in a software table.!®»17>5°
`The virtual mode bit indicated the state which the machine
`would be in if the software were executing directly on the
`bare machine. Instructions which were insensitive to the
`actual mode of the machine were allowed to execute
`directly on the bare machine without VMM intervention.
`All other
`instructions were trapped by the VMM and
`simulated in software using the virtual mode bit
`to
`determine the appropriate action in each case.
`In general, the non-privileged instructions are executed
`directly and certain privileged instructions must be trapped
`and simulated. However, this cannot always be donesince
`there may be some instructions which are sensitive to the
`processor mode mapping yet are not privileged — i.e., not
`automatically trapped when executed in non-privileged
`mode. As a result, it is often impossible to support virtual
`machine
`systems
`using
`this partial
`software
`construction. ® 3? >33
`On third-generation virtual machine systems, the virtual
`machine’s memoryis usually supported through use of the
`system’s memory mapping mechanism. The memoryofthe
`virtual machine must retain the properties of real memory,
`such as linear addresses from zero and special meanings to
`certain interrupt control locations. Memory mapping used
`in current systems has been both simple relocation and
`paging. If the host machine is paged, the virtual machines
`
`June 1974
`
`may include the paging mechanism as well.?°*©° In this
`case, the VMM must manipulate the page tables in order to
`map paged addresses within the virtual machines into their
`corresponding real addresses. Current
`techniques utilize
`some awkward and unnecessary software overhead but
`recent advances have been madein this area.°?>34
`
`Since I/O instructions are usually privileged, attempted
`execution by software on a virtual machine causes a trap to
`the VMM. At this point the VMMis able to translate device
`and memory addresses before issuing an I/O instruction on
`behalf of the virtual machine. When an I/O completion
`interrupt returns to the VMM, it is reflected back to the
`appropriate virtual machine. Since I/O operations may
`occur with a “relatively low frequency,” the performance
`degradation introduced by this VMM software intervention
`should be tolerable. Current computer architectures require
`VMM software intervention to maintain system integrity
`since an improperly written channel program can interfere
`with other virtual machines or the VMMitself.? A side
`benefit of software intervention is the ability to map I/O
`requests for one device into requests for another! *?® or to
`provide a virtual machine with special devices which have
`no real counterpart. 4°?5
`The considerations of how the virtual machine mapsare
`constructed for various systems and which machines admit
`of such a mapping has been discussed in the liter-
`ature.1°>!7-39:31,33 A recent study has even used formal
`mathematical
`techniques to establish sufficient architec-
`tural
`conditions
`for
`third-generation virtual machine
`support.°® These results have led a numberof researchers
`to make hardware modifications to current machines in
`order to support virtual machines.° * °*
`
`a number of
`Virtualizable Architectures Recently,
`researchers have proposed newarchitectures — i.e., virtual-
`izable architectures — which provide features to directly
`support virtual machines.?* 334 47>48 The arguments for
`these architectures include:
`
`e System hygiene. There is no intrinsic reason why
`virtual machine support must be based on the trap
`and simulation approach since it
`is clumsy and
`awkward.
`
`e Software simplicity. Virtualizable architectures
`would make the VMManeven smaller and simpler
`program and further contribute to the reliability/
`security appeal of VM’s.
`e System performance. Machines designed to sup-
`port virtual machines should operate even more
`efficiently than third-generation VM systems.
`
`IBM has recently announced VM/370 Release 2 which
`includes a firmware modification, called VM-assist, to the
`standard System/370.'? 4? 44 While very little information
`is currently available about VM-assist, it seems to have some
`of the characteristics of the virtualizable architectures.
`
`to illustrate the
`In order
`The Hardware Virtualizer
`principles of virtualizable architectures, we will sketch the
`design of the author’s Hardware Virtualizer which has been
`described in detail in the literature.??°?*°°° The theory is
`based on the following arguments:
`e The key issue involved in VM’s is the instantan-
`eous relationship between the resources of the
`virtual and real machines.
`
`37
`
`a
`
`.
`
`

`

`identify the sets of resources of the
`e We must
`virtual machine and the real machine and define a
`map between them,called an f-map.
`e The f-map transformsa virtual resource name into
`its corresponding real resource name.
`e The f-map must be
`invisible to all software
`executing on the virtual machine.
`e The VMM software running on the real machine
`manipulates and invokes the f-map, and is given
`control on an f-map violation, called a VM-fault.
`e The design extends directly for recursion, in which
`case the f-map maps adjacent
`levels of virtual
`resources. In order to run a VM it is necessary to
`compose — i.e., combine — all the maps together.
`Faults must be passed to the VMM at
`the
`appropriate level.
`privileged/non-
`e Any
`other
`structure— e.g.,
`privileged modes — is independentof virtualization
`and behaves as it would on the original machine.
`The resource sets relevant to the virtual machine model
`are represented by the shaded areas of Figure 2, shown
`earlier. These sets are the real resource set and the two
`virtual resource sets. The corresponding f-maps are not
`illustrated in the figure.
`Figure 3 illustrates the extension of the virtual machine
`model
`to include recursion. The model indicates how a
`VMM may be run on the basic machine interface of a
`virtual machine — e.g., V1. This VMM in turn creates two
`
`virtual machines, V1.1 and V1.2, on which are running
`conventional operating systems — i.e., privileged software
`nuclei.
`identifies the five shaded
`The virtual machine model
`areas of the figure as distinct resource sets and indicates the
`mapping relationship among them. Thusa resource name of
`V2 must be mapped by f2 to be transformed into a real
`resource of R. On the other hand, a resource of V1.1 must
`be mapped consecutively by both f1 1 and fj in order to be
`transformed into its corresponding resource of R.If there is
`a violation in applying the mapping of f1,1, a VM-fault
`passes control to the VMM in Vj}. Similarly, a violation of
`fj faults to the VMM in R.Asin the nonrecursive model,
`local mapping structure pertaining to user programs is
`hidden within the resource sets and is ignored.
`Direct application of this theory yields the design of the
`Hardware Virtualizer. Goldberg discusses
`in detail
`the
`development of a generic Hardware Virtualizer with arbi-
`trary choices of target architecture and virtual machine
`.map. There are a number ofsubtle issues which arise in
`the design but
`the key concept
`is the direct mirroring
`in hardware of
`the virtual machine model presented
`above. This requires hardware/firmware supportto:
`e represent the f-maps,
`® activate a virtual machine,
`e compose the f-maps (and possibly local maps)
`together during resource referencing, and
`® pass control to the correct VMM on a VM-fault.
`
`
`
`
`BASIC
`MACHINE
`INTERFACE:
`
`fy
`
`
` VIRTUAL
`BASIC
`
`SMACHINE
`INTERFACE
`
`MACHINES
`
`
` ¢ EXTENDED
`
`# |
`
`EXTENDED
`MACHINES
`
`EXTENDED
`MACHINE
`INTERFACE
`
`MACHINE
`INTERFACE
`#2
`
`Figure 3. Virtual Machine Model with Recursion
`
`38
`
`COMPUTER
`
`TT,
`.
`
`

`

`In Goldberg?*? the map composeris sketched using a small
`number of scratchpad and associative registers which
`“remember”
`the most
`recently composed (mapped)
`resource names.
`It
`is claimed that because of program
`locality considerations,°® the hit ratios for these associative
`registers will be high, and hence the instruction execution
`rate with the Hardware Virtualizer should be comparable to
`the real machine’s rate for a wide range of f-maps and target
`architectures.
`
`Performance
`
`There have been numerousstudies of the performance
`characteristics of the virtual machine systems CP-67,°°°
`VM/370,’ and also the virtual machine facility under
`UMMPS.’° However, since these three systems are also
`multiprogramming systems and virtual storage systems,
`much of the work hasrelated to these other characteristics,
`rather than the purely virtual machine aspects.
`In this section we will investigate some of the sources of
`overhead in virtual machine systems. Then wewill examine
`some of the techniques that have been used to improve VM
`performance. Finally, we will
`look at some interesting
`performance
`problems which
`are
`unique
`to virtual
`machines.
`
`Sources of Overhead There are demonstrable penalties
`in running a jobstream on a virtual machine instead ofa real
`machine. These penalties include the extra resources — e.g.,
`main memory and processor cycles needed by the VMM —
`and the potential drop in system throughput whichresults.
`The extra CPU cycles are sometimes called processor
`overhead, or just overhead, and the additional amount of
`time to process a jobstream is called stretchout.>° °°
`Studies often run jobstreams under a single virtual
`machine in order
`to separate out unusual multipro-
`gramming effects. For example, Young has reported that a
`measurementrun of a System/360 DOS jobstream run under
`control of VM/370 produced better throughput, due to
`multiprogramming, than running the samejobsserially on
`the same computing system.” ”
`Some of the principal sources of overhead in virtual
`machine systemsinclude:
`e@ Maintaining the status of the virtual processor. The
`complete integrity of all visible registers, status
`bits, and reserved memory (interrupt control)
`locations must be preserved.
`Third-
`instructions.
`e Support of privileged
`generation virtual machine systems have expended
`processor overhead to trap and simulate privileged
`instructions.
`e Support of Paging Within Virtual Machines. Soft-
`ware techniques are currently used to transform a
`paged address in a VM into an address in the VM
`and finally into a real memory address.
`e Console Functions. The operator’s panel andlights
`are simulated in software. This overhead is not
`invokedas frequently as the others cited above.
`Additional sources of overhead include the reflection of
`exceptions and I/O interrupts to the virtual machines,
`support of virtual timers and clocks, and the translation of
`1/O channel programs before the VMM initiates I/O. For
`virtual machines supported with paged memory mapping,
`channel program translation can be a significant source of
`overhead.
`
`June 1974
`
`Improving Performance A number of techniques for
`improving the performance of virtual machine systems have
`been developed at various installations. While some are ad
`hoc approaches aimed at reducing overhead arising from
`third-generation architectural weaknesses, others have gen-
`eral applicability to virtualizable architectures as well. The
`techniques can roughly be divided into the following
`classes:
`e policies,
`® compromises to virtual machine architecture,
`e@
`improved or new mechanisms.
`
`Policy Policy approaches to performance improvement
`have addressed both overhead and installation management
`issues. For example, real system resources can be dedicated
`in order to guarantee a certain performance level for a
`particular preferred virtual machine.®' Resources include
`percentage of CPU time, a real I/O channel andits devices,
`and page frames of main memory.*?
`An interesting resource allocation policy concerns the
`so-called “‘virtual= real’? option which assigns virtual
`addresses to identical real addresses even though page tables
`are still used to establish and limit addressability.**»°!>7°
`This option arises because existing virtual machine hard-
`ware architectures feature CPUs which support paging but
`I/O channels which do not. By allocating the same virtual
`and real addresses,
`it may be possible to eliminate the
`overhead
`normally incurred
`in
`channel
`program
`translation.*
`Other policy approachesto virtual machine performance
`improvement affect
`the virtual machine definition and
`system generation of an operating system for it. Paging
`operations by the VMM are typically more efficient than
`file I/O operations by the operating system on the virtual
`machine.°*!* Thus, it is sometimes a good strategy to have
`a very large virtual machine memory definition even though
`it would increase the amount of paging.*°® This will
`decrease the numberoffile I/O operations and mayyield a
`net performance improvement.
`Another approach is
`to “streamline” the VM defini-
`tion.43>7? If it is known that software running on a virtual
`machine will never use certain features, the VMM can be
`informed and may be able to provide more efficient
`support. In existing virtual machine systems, which support
`real-time interval
`timers, certain self-modifying channel
`programs, or paging in the VM’s,
`is very costly. Perform-
`ance is improved by ensuring that an operating system
`running on a particular virtual machine will not use these
`features.
`
`Interface Another performance
`Compromising the
`improvement approach compromises the VMM/OSinter-
`face.’?? The VM architecture is routinely altered for certain
`specific operating systems by moving functions from that
`operating system to the VMM.*? Thus,
`in addition to
`providing pure VM’s for those applications which needit,
`the VMMalso providesa slightly extended virtual machine
`which has a few new instructions which are effectively
`supervisor calls to the VMM. In CP-67 these calls were
`implemented via the customer engineering diagnose instruc-
`tion, which is normally a model-dependentillegal instruc-
`tion. A number of installations have experimented with
`specialized console** and file system*®*>* support pro-
`vided via diagnose.
`
`*There still may be a need to check addresses for boundsviolations.
`
`39
`
`a
`
`.
`
`

`

`algorithm which cannot work effectively, and (2) the actual
`The unfortunate consequence of this approach is that it
`results of the algorithm may be counterproductive — i.e., a
`introduces
`the danger of producing a VMM with an
`incompatible interface. Thus, an operating system written
`random allocation algorithm might be better.
`for
`this interface may not
`run on any other “virtual
`Some example situations where this phenomenon has
`been observed are:
`machine” or even on the real machine.*
`the
`One proposed solution to this dilemma is to let
`e disk optimization for
`a disk which itself
`is
`software determine whetherit is running onareal or virtual
`mapped;
`machine.”? If an operating system believes it is on a real
`e spooling of unit record I/O in a virtual machine
`machine, it behaves normally. If it discovers that it is ona
`and then additional spooling by the VMM;
`virtual machine, it can take shortcuts which might reduce
`@ paging by an operating system on the VM and
`overhead. For example, it might ignore error codes which
`paging by the VMM.
`the virtual machine knows have been set by the VMM or
`The last situation arises, for example, when the IBM
`use diagnose-type support for certain functions.
`OS/VS2 operating system is run on a virtual machine under
`The debate over “pure” vs. “impure” virtual machines
`VM/370.
`In that case there are two independent page
`has been going on for several years.'°’?7»?° The “purists”
`replacement algorithms — one on the virtual machine and
`argue that an impure virtual machine will suffer the same
`one by the VMM. In a recent analysis*”?
`it has been
`disadvantages as a conventional operating system’s non-
`demonstrated that there are operating regions(i.e., sizes of
`standard extended machine interface. The “impurists”
`memory) and page replacement algorithms for which each
`counter by pointing to the performance improvements over
`page fault handled in the VM will cause a second page fault
`conventional virtual machine systems. Furthermore, they
`which must be handled by the VMM. Furthermore, the
`observe that the “impure” approachleads to clear, hierarch-
`well-known “least recently used” (LRU) page replacement
`ically organized operating systems, even if they are not
`algorithm is susceptible to this phenomenon.
`virtual machines.’ 8
`
`Improved hardware
`Improved or New Mechanisms.
`architectures for virtual machines arise from performance
`considerations, as well as system organization. Much of the
`overhead,
`identified above,
`is introduced because of an
`inadequate hardware base in present machines. Some of the
`techniques that have been developed are merely ad hoc
`approaches to these difficulties. A particular source of
`overhead in third-generation virtual machines is the trap
`and simulation of privileged instructions normally per-
`formed by the VMM. The System/370 virtual storage
`operating systems makesignificantly heavier use of certain
`privileged instructions than did their OS/360 real memory
`predecessors.”*, As a result,
`IBM has measured greater
`processor overhead in running the virtual storage operating
`systems under VM/370 Release 1. The solution has been to
`develop VM-assist, a firmware modification to the System/
`370 which eliminates the need for much ofthe privileged
`instruction software simulation.** Preliminary performance
`information for VM/370 Release 2 indicates success in
`reducing this processor overhead.’ > *?
`Similar success is anticipated for virtualizable architec-
`tures such as the Hardware Virtualizer** or the Newcastle
`Recursive Virtual Machine.*® For certain choices of
`resource maps, these machines should eliminate other forms
`of processor overhead. In particular, page table composi-
`tion, channel program absolutization, virtual
`timers, and
`other virtual machine functions can be performed directly
`by hardware/firmware.
`
`Unique Performance Problemsfor Virtual Machines Even
`if the direct overhead problems of VMs are solved (as
`above) a number of unique virtual machine performance
`problems may remain. Operating systems include algor-
`ithms for effectively managing the real resources of the
`computer system. In virtual machine systems these virtual
`resources may not correspond precisely to real resources,
`and consequently unusual performance problems may
`arise.”? Two principal penalties are incurred in this case:
`(1) CPU time and other resources are wasted utilizing an
`
`*In contrast, an operating system for a streamlined interface can be
`run on a real machine.
`
`40
`
`Practice
`
`The versatility and flexibility of virtual machine systems
`is only beginning to be understood. Virtual machines have
`been successfully utilized in a number of application areas
`on small, medium, and large-scale computer systems. We
`will examine a few of these uses.
`
`Installation Management Virtual machines allow sig-
`nificant
`scheduling flexibility by permitting privileged
`software development,
`test and diagnostic functions, and
`multiple operating system execution concurrently with
`production uses of the system. The individual operating
`systems need not be identical (e.g.,
`IBM’s OS/360 and
`DOS/360 under VM/370). They may also be different
`versions
`of
`the
`same
`system (e.g., Releasen and
`Release n+1). In the first case, VM’s can aid in unifying
`installation procedures. In the second case they can greatly
`simplify the new release installation and conversion period.
`An example ofinstallation unification is the integration
`of a batch operating system and an interactive terminal
`system on common hardware.°° Srodowa and Bates’° have
`reported on their success in using VM techniques to unify
`IBM’s OS/360 with the Michigan Terminal System (MTS)
`under UMMPS? at Wayne State University. VM/370 has
`been used to unify DOS/VS with CMS.*?
`Virtual machines can alleviate the new release “‘trauma”
`by permitting system generation and testing of the new
`release simultaneously with production uses of the old
`release, and by permitting the old and new releases to be
`run concu