Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site oakhill.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!ut-sally!oakhill!davet
From: davet@oakhill.UUCP (Dave Trissel)
Newsgroups: net.unix-wizards
Subject: VM on MC680x0?  Answered
Message-ID: <307@oakhill.UUCP>
Date: Wed, 30-Jan-85 03:35:15 EST
Article-I.D.: oakhill.307
Posted: Wed Jan 30 03:35:15 1985
Date-Received: Sun, 3-Feb-85 01:03:34 EST
Organization: Motorola Inc. Austin, Tx
Lines: 69
Xref: seismo net.unix-wizards:11720

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!davet