gnu@sun.uucp (John Gilmore) (01/23/85)
> A cursory reading of the M68000 manual indicates that them M68010 and > M68020 are capable of supporting hypervisors. The 68010 and 68020 are ALMOST capable of supporting hypervisors. Unfortunately there is one thing you can't simulate: RTE (Return from Exception) into the middle of an instruction as a bus error recovery. If the virtual machine trashes its stack, there is no way for the hypervisor to validate the stack other than to run a real, privileged RTE on that stack -- which could hang or kill the machine, since it contains numerous internal registers including the microprogram counter (uPC). The chip itself is pretty lax about validating the stack; it will load anything that looks half reasonable. In fact, in the 68020 this is how the chip is jumped into test microcode in Motorola manufacturing tests. IBM didn't have this problem because they take the "undo all the side effects" approach to taking page faults in mid instruction, rather than "save everything and restore it later". Other than that, it makes a fine VM machine -- quite a bit better than IBM's in hardware support, since it lets the hypervisor do things like simulate memory mapped I/O devices transparently. If you take a page fault you have two options: supply the data and set a bit -- the CPU continues the instruction -- or don't supply the data, then the CPU will retry the access, hoping that you have since brought in the page that faulted. With the first option you can do things like define a "software UART" that looks to the virtual machine exactly like a hardware UART, but gives the user memory accesses to the hypervisor to do whatever it wants with them. Now if only 4.2BSD had that feature! (Hiding a process behind memory, e.g. a file.)
guy@rlgvax.UUCP (Guy Harris) (01/26/85)
> The 68010 and 68020 are ALMOST capable of supporting hypervisors. > Unfortunately there is one thing you can't simulate: RTE (Return > from Exception) into the middle of an instruction as a bus error > recovery. If the virtual machine trashes its stack, there is no > way for the hypervisor to validate the stack other than to run a > real, privileged RTE on that stack -- which could hang or kill the > machine, since it contains numerous internal registers including > the microprogram counter (uPC). The chip itself is pretty lax about > validating the stack; it will load anything that looks half reasonable. The GE 645 (original MULTICS machine) had the same problem - there was a "store CPU state" instruction (don't remember the actual name) and a "restore CPU state" instruction used to handle page faults in the middle of complex instructions. MULTICS solved this by having the kernel (ring 0) validate the state to be restored before it did the restore instruction. The state included the doubleword (72 bits) containing the instruction, which was used as a cute way to handle the problem of continuing after breakpoints. Normally, if you set a breakpoint by stuffing in a breakpoint trap instruction, to continue after the breakpoint you have to restore the original instruction, single-step over it, put the breakpoint trap back, and continue. The MULTICS debugger just replaced the breakpoint trap instruction in the instruction doubleword image with the real instruction and restored the state. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
rpw3@redwood.UUCP (Rob Warnock) (01/26/85)
+--------------- | > A cursory reading of the M68000 manual indicates that them M68010 and | > M68020 are capable of supporting hypervisors. | The 68010 and 68020 are ALMOST capable of supporting hypervisors. | Unfortunately there is one thing you can't simulate: RTE (Return | from Exception) into the middle of an instruction as a bus error | recovery. If the virtual machine trashes its stack, there is no | way for the hypervisor to validate the stack other than to run a | real, privileged RTE on that stack -- which could hang or kill the | machine, since it contains numerous internal registers including | the microprogram counter (uPC). +--------------- Actually, John, I think you CAN simulate the RTE, it's just messy. You have to have a routine in the (true) kernel which knows how to actually simulate each and every instruction in the machine. You then "wind-forward" the interrupted instruction (in the VM machine) until it is finished (checking for possible bus errors on each mem ref). There is (supposed to be) enough information on the stack for you to do that. Ugh! Somebody at Motorola want to comment? Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
josh@v1.UUCP (Josh Knight) (01/27/85)
> Other than that, it makes a fine VM machine -- quite a bit better than > IBM's in hardware support, since it lets the hypervisor do things like > simulate memory mapped I/O devices transparently. Recent IBM hardware has better (at least different) support for "hypervisors". See "System/370 Extended Architecture: Facilities for Virtual Machines" by P.H. Gum, in IBM Journal of R&D Vol. 27, No. 6 (November 1983), pp. 530-544 for a discussion of hardware facilities for virtual machines (as well as references related to other discussions of VM/CMS in this forum). The opinions expressed are my own, not those of my employer. Josh Knight, IBM T.J. Watson Research josh at YKTVMX on BITNET, josh.yktvmx.ibm on CSnet, ...!philabs!v1!josh
geoff@desint.UUCP (Geoff Kuenning) (01/28/85)
In article <142@redwood.UUCP> rpw3@redwood.UUCP (Rob Warnock) writes: >| The 68010 and 68020 are ALMOST capable of supporting hypervisors. >| Unfortunately there is one thing you can't simulate: RTE (Return >| from Exception) into the middle of an instruction as a bus error >| recovery. >Actually, John, I think you CAN simulate the RTE, it's just messy. You have >to [know how to emulate the microcode for the RTE]... But do we really need to do all this? The software is permitted to change only certain limited fields in the saved state; the format of the other stuff isn't even documented, and may conceivably vary from rev to rev of the chip (I seem to remember this was a problem with somebody's multiprocessor 68010 system). When the VM gets a bus error, save the state vector someplace internally. Then, when it does an RTE, find the matching state vector and do a comparison, allowing for changes only in legal places. If there is a problem, simulate a format exception in the VM. P.S. I am moving this discussion to net.micro.68k, since that seems to be a more reasonable place than unix-wizards. -- Geoff Kuenning Unix Consultant ...!ihnp4!trwrb!desint!geoff