davet@oakhill.UUCP (Dave Trissel) (01/30/85)
Michael Cruess here at Motorola has copied to me a posting by Rob Warnock
on net.unix-wizards (I do not subscribe) concerning a possible problem
for virtual machine processing on the MC68010 and later family parts.
The discussion centers on how a hypervisor (an operating system providing
for virtual machine environments by executing other operating systems in User
mode) could simulate an RTE for a virtual machine running under its control.
I think that by following precisely the steps that would occur it can be seen
that the amount of work is far less than has been supposed.
Our example starts out with a user task running under a virtual operating
system (itself running under the hypervisor) which attempts to access a
paged out piece of memory. Since the virtual operating system's memory
management tables would not have this page marked available, neither would
the hypervisor's "real" memory system have it available. Thus a bus error
exception would occur sending control not to the virtual operating system
but to the hypervisor.
Now the hypervisor determines that such an address does not exists for the
virtual machine being implemented. Thus a dummy Bus Exception stack frame
is built on the virtual operating system's supervisor stack reflecting the
bus fault encountered in terms of the virtual machine's environment. The
important thing to notice here is that the only portion of the stack frame
which needs to be "filled in" is the portion described by Motorola as having
meaning to the an operating system's bus exception routine. This would be
things like the function code involved, read or write condition, initial
settings of retry bits, etc. All the rest can be left as garbage since the
virtual operating system is totally unaware of what that portion of the
stack means and is not allowed to alter it anyway.
Now the virtual operating system examines the status of the psuedo bus error
and eventually reassigns the page to the task (which would itself probably
be intercepted by the hypervisor catching memory management configuration
changes.) Now the virtual operating system indicates bus retry in the psuedo
exception frame (although a completion by simulation of the bus cycle is also
possible here) and does the infamous RTE which is the subject of this posting.
The hypervisor will see that an virtual RTE is being done. All that it will
have to examine and verify are those fields defined as alterable by the
particular machine being emulated. This is far less work than say simulating
a virtual machine's MOVE SR,<ea> which requires the capability of emulating
all possible addressing modes allowed in that instruction.
[To digress, lets assume that the hypervisor wishes to guarantee that the
undefined portions of the psuedo bus exception stack frame have not been
damaged by a bug in the virtual operating system being tested. This is
important because we may be debugging an operating system and we don't want
it to fail on real hardware after it "seemed to work" on a virtual machine.
All that need be done is for the hypervisor to write any known pattern into
the undefined portion of the stack frame and check for its validity when the
virtual RTE is intercepted. (A checksum may suffice here.) For the ambitious
one could use random patterns which would allow the detection of this type
of bug which even a REAL CHIP may let pass! (For example assume a bit is
always set on and just happens to always be on anyway when presented in a
bus exception frame of a real chip.) Personally, I don't think its worth
the effort to do anything about this at all.]
Back to the hypervisor simulating the virtual RTE. Assuming a bus retry was
indicated then the hypervisor simply does its own RTE back to the emulated
environment. The bus cycle will complete normally (remember the interception
of the mapping fixup in the virtual OS) and the emulation will continue
normally.
Now, wasn't that easy? :-)
I hope this has answered the questions involved.
Motorola Semiconductor Inc. Dave Trissel
Austin, Texas {ihnp4,ctvax,seismo,gatech}!ut-sally!oakhill!davetpugs@sun.uucp (Tom Lyon) (02/03/85)
> Back to the hypervisor simulating the virtual RTE. Assuming a bus retry was > indicated then the hypervisor simply does its own RTE back to the emulated > environment. The bus cycle will complete normally (remember the interception > of the mapping fixup in the virtual OS) and the emulation will continue > normally. > > Now, wasn't that easy? :-) No, it's not that easy. There's no guarantee that the virtual RTEs occur immediately after the virtual bus error; the real operating system must be able to pair every virtual RTE to a preceding virtual/real bus error. Any number of tasks in the virtual operating system may be waiting to have their pages brought in so that the virtual RTEs may occur, so the real operating system has to keep the real bus error information around for a long time (forever). However, there is no guarantee the the virtual RTE will ever occur (virtual segmentation fault), so either the real operating system will slowly accumulate unused bus error information or else it must have some disgusting heuristic for knowing when to get rid of it. The way around the problem is to push the actual information onto the virtual operating system's stack and let it do whatever with it. Detection of invalidly modified info on RTEs can be done with a "signature" such as checksumming or encryption. However, checksumming is easily fooled by a malicious virtual operating system and encryption is expensive. I think Motorola blew it on this one; I don't think we'll see a virtual machine environment as useful and reliable as VM/370 on the MC680x0. Tom Lyon Sun Microsystems, Inc.