Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!dciem!nrcaero!pesnta!amdcad!decwrl!sun!pugs
From: pugs@sun.uucp (Tom Lyon)
Newsgroups: net.unix-wizards
Subject: Re: VM on MC680x0?  Answered
Message-ID: <1976@sun.uucp>
Date: Sat, 2-Feb-85 18:12:02 EST
Article-I.D.: sun.1976
Posted: Sat Feb  2 18:12:02 1985
Date-Received: Thu, 7-Feb-85 07:31:36 EST
References: <307@oakhill.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 30

> 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.