13.07.2015 Views

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

22 Introduction Chapter 1created for each user who logs on. Its control panel is mapped onto the user’s terminal,and buttons are ‘‘pushed’’ by typing in appropriate commands. These commandsallow for initial program load (to start up CMS, for instance) and for interruptingthe virtual machine.Virtual-machine operating systems are complex. To provide acceptable speed, thehardware executes most instructions directly. One might think that the virtualizing kernelV can run all its processes P i in privileged state and let them use all the hardwareinstructions. However, privileged instructions are just too dangerous to let processes usedirectly. What if P i executes the halt instruction? Instead, V must run all P i in nonprivilegedstate to prevent them from accidentally or maliciously interfering with eachother and with V itself. In fact, virtual-machine operating systems cannot be implementedon computers where dangerous instructions are ignored or fail to trap in nonprivilegedstate. For example, the PDP-11/45 in non-privileged state fails to trap onseveral dangerous instructions. In general, an instruction is dangerous if it performstransput, manipulates address-translation registers (discussed in Chapter 3), or manipulatesthe processor state (including interrupt-return instructions and priority settinginstructions).To let P i imagine it has control of processor states, even though it does not, Vkeeps track of the virtual processor state of each P i , that is, the processor state of the virtualmachine that V emulates on behalf of P i . This information is stored in P i ’s contextblock inside of V. All privileged instructions executed by P i cause traps to V, whichthen emulates the behavior of the bare hardware on behalf of P i .If P i was in virtual non-privileged state, V emulates a trap for P i . This emulationputs P i in virtual privileged state, although it is still run, as always, in physicalnon-privileged state. The program counter for P i is reset to the proper trap addresswithin P i ’s virtual space. (We will see in Chapter 3 how virtual space is managedfor virtual machine operating systems.) We say that V has reflected the trap to P i .If P i was in virtual privileged state, V emulates the action of the instruction itself.For example, it terminates P i on a halt instruction, and it executes transput instructionsinterpretatively.Some dangerous instructions are particularly difficult to emulate. Transput can bevery tricky. Channel programs (discussed in Chapter 5), which control some sophisticatedtransput devices, must be translated and checked for legality. Self-modifying channelprograms are especially hard to translate. The virtualizing kernel may wish to simulateone device by another, for example, simulating a printer on a disk or a small disk ona part of a larger one. A device-completion interrupt can indicate that a transput operationstarted on behalf of some P i has terminated. In this case, the interrupt must bereflected to the appropriate P i . In contrast, emulating a single transput operation for P imay require several transput operations, so device-completion interrupts often indicatethat V may proceed to the next step of emulating an operation already in progress. Suchinterrupts are not reflected. If the computer communicates with devices through registerswith addresses in main store, all access to that region of store must cause traps so that Vcan emulate the transput. Address translation also becomes quite complex. We willdefer discussing this subject until Chapter 3.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!