ford@crash.CTS.COM (Michael Ditto) (11/09/87)
In article <17213@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > Real multiple-operating-system machines do exist. This requires >what is known as a "hypervisor", an operating system whose users are >operating systems themselves. > [ ... ] > Interestingly, the M68000, when provided with an MMU, has enough >support to allow a hypervisor. But I have never heard of one being written. The 68000 can not fully support a MMU (It does not save enough state information during a page fault). The 68010 works fine for this, though. There is one other problem with using the 68000 to run a virtual machine (or hypervisor, as you call it): Some operating system code can be called either from supervisor or user mode and needs to look at the supervisor-bit in the status register to see what mode the CPU is in. On the 68000 this bit can be looked at by user programs (such as the "guest" OS), and therefore would cause problems for such an OS running on a virtual machine. The 68010 handles this problem as well, by making the status register readable only in supervisor mode (the condition codes can always be read). That way the "real" OS can handle the privilege violation in an appropriate way. I beleive Motorola has used virtual machine techniques to develop and test some of their operating systems. Followups have been directed at comp.sys.m68k. -- Mike Ditto -=] Ford [=- P.O. Box 1721 ford%kenobi@crash.CTS.COM Bonita, CA 92002 ford@crash.CTS.COM
jfh@killer.UUCP (The Beach Bum) (11/11/87)
[ Responding to article about 68000's can't restart a faulted instruction. ]
Interestingly enough, some manufacturer built a machine with two 68000's.
The main 68K ran along until a page fault. Then (and this is from memory)
the second 68K loaded the faulted page while the first was halted waiting
for DTACK to be asserted. Once the page was loaded, the second 68K
asserted DTACK for the first CPU, and then waited for the next page fault.
What machine was this? This isn't a quiz, I'm asking the question ...
- John.
--
John F. Haugh II SNAIL: HECI Exploration Co. Inc.
UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600
...!ihnp4!killer!rpp386!jfh Dallas, TX. 75243
"Don't Have an Oil Well? Then Buy One!" (214) 231-0993tim@ism780c.UUCP (Tim Smith) (11/11/87)
Maybe Motorola can write a working virtual machine for the 680xx, but
can anyone else?
You have to have some way of making sure that long stack frames from
things like bus errors are valid before allowing them to be used.
These frames are full of undocumented fields that can can cause all
kinds of problems if they contain bad data.
Example: take a valid bus error stack frame, and change the return address,
and then return from the bus error. This can cause the processor to go
off into hyperspace.
--
Tim Smith, Knowledgian {sdcrdcf,uunet}!ism780c!tim
tim@ism780c.isc.comtim@amdcad.AMD.COM (Tim Olson) (11/13/87)
In article <2051@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes: | Interestingly enough, some manufacturer built a machine with two 68000's. | The main 68K ran along until a page fault. Then (and this is from memory) | the second 68K loaded the faulted page while the first was halted waiting | for DTACK to be asserted. Once the page was loaded, the second 68K | asserted DTACK for the first CPU, and then waited for the next page fault. | | What machine was this? This isn't a quiz, I'm asking the question ... Many machines apparently used this trick before switching to a 68010. Valid's SCALD workstations come to mind as one... -- Tim Olson Advanced Micro Devices (tim@amdcad.amd.com)
wheels@mks.UUCP (11/14/87)
In article <2051@killer.UUCP>, jfh@killer.UUCP (The Beach Bum) writes: } } Interestingly enough, some manufacturer built a machine with two 68000's. } The main 68K ran along until a page fault. Then (and this is from memory) } the second 68K loaded the faulted page while the first was halted waiting } for DTACK to be asserted. Once the page was loaded, the second 68K } asserted DTACK for the first CPU, and then waited for the next page fault. } What machine was this? This isn't a quiz, I'm asking the question ... } - John. I remember that too. I think it was the Lisa, but don't quote me.
jejones@mcrware.UUCP (James Jones) (11/14/87)
--------------------------------------- Dunno about two 68000s, but MicroDaSys way back when sold a box built on similar principles that used a 6809 to do the grunt work of paging. If people want, I'd go through some old BYTEs and dig up the ad. James Jones
ncoverby@ndsuvax.UUCP (Glen Overby) (11/15/87)
In article <19097@amdcad.AMD.COM> tim@amdcad.UUCP (Tim Olson) writes: |In article <2051@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes: || Interestingly enough, some manufacturer built a machine with two 68000's. || The main 68K ran along until a page fault. Then (and this is from memory) || the second 68K loaded the faulted page while the first was halted waiting || for DTACK to be asserted. Once the page was loaded, the second 68K || asserted DTACK for the first CPU, and then waited for the next page fault. I recall a Motorola tech note describing a small virtual memory system using two 68000s as described above. I don't know the tech note number or anything like that. -- Glen Overby Bitnet: ncoverby@ndsuvax UUCP: uunet!ndsuvax!ncoverby
farren@gethen.UUCP (Michael J. Farren) (11/15/87)
In article <316@mks.UUCP> wheels@mks.UUCP (Gerry Wheeler) writes: [responding to a query about machines using two 68000s for page fault processing] > >I remember that too. I think it was the Lisa, but don't quote me. I wouldn't dream of it. Especially since you were wrong (Lisas only have one 68000). 'Twere an early Apollo that did that, and I don't know if they were the only ones - it's a well-know kludge. -- ---------------- Michael J. Farren "... if the church put in half the time on covetousness unisoft!gethen!farren that it does on lust, this would be a better world ..." gethen!farren@lll-winken.arpa Garrison Keillor, "Lake Wobegon Days"
dje@datacube.UUCP (11/16/87)
I think the machine with two 68000's to detect page faults was from Apollo. Dave Erickson ---------------------------------------------- ------ Datacube Inc. / /| 4 Dearborn Rd. ------ | Peabody, Ma 01960 || \| | ihnp4!datacube!dje || /|/ Human:(617)535-6644 ------ Fax: (617)535-5643
geof@imagen.UUCP (Geoffrey Cooper) (11/16/87)
In article <2051@killer.UUCP>, jfh@killer.UUCP (The Beach Bum) writes: > [ Responding to article about 68000's can't restart a faulted instruction. ] > Interestingly enough, some manufacturer built a machine with two 68000's. > > What machine was this? This isn't a quiz, I'm asking the question ... I believe that the first machines built by apollo computer used this trick. Also, many machines sold by Masscomp did. - Geof-- {decwrl,sun,saber}!imagen!geof
henry@utzoo.UUCP (Henry Spencer) (11/20/87)
> You have to have some way of making sure that long stack frames from > things like bus errors are valid before allowing them to be used. > These frames are full of undocumented fields that can can cause all > kinds of problems if they contain bad data. The generic solution to this is not to let the user's operating system meddle with the frames. Keep the *real* frame somewhere private. Give him a fake one, with the documented fields filled in from the real one, and the rest full of magic numbers and checksums and so on. When he tries to do a return using the fake frame, check the checksums etc. If they're wrong, give him a simulated hardware failure. If they're right, give him a return using the real frame, adjusted to match any legitimate changes he's made to the fake one. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (11/21/87)
>The generic solution to this is not to let the user's operating system >meddle with the frames. Keep the *real* frame somewhere private. Give >him a fake one, with the documented fields filled in from the real one, >and the rest full of magic numbers and checksums and so on. When he tries >to do a return using the fake frame, check the checksums etc. [...] There is still a real problem here. If the kernel keeps a copy of the real frames, it will have to keep them *forever* (possibly even across reboots), since a user might want to restart his faulted program at any time. This puts the burden of storing a possibly infinite number of bytes, on the kernel. If one uses a checksum validation scheme, and passes a checksummed frame to the user, once still has a security problem. Unless the checksumming algorithm is secret, a user can just validate his own phoney frame. I'm of the opinion that 680x0 exception frames are a botch. They might be a quick fix to instruction restart problem, but they are poorly inplemented. If Motorola had only included a validate_user-mode_exception-frame instruction we would be home free. Let the 680x0 tell us if the frame is cool. --- Wolfgang Rupprecht UUCP: mit-eddie!mgm.mit.edu!wolfgang (or) mirror!mit-mgm!wolfgang ARPA: wolfgang@mgm.mit.edu (IP addr 18.82.0.114)
tim@ism780c.UUCP (11/25/87)
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) writes:
< >The generic solution to this is not to let the user's operating system
< >meddle with the frames. Keep the *real* frame somewhere private. Give
< >him a fake one, with the documented fields filled in from the real one,
< >and the rest full of magic numbers and checksums and so on. When he tries
< >to do a return using the fake frame, check the checksums etc. [...]
<
< There is still a real problem here. If the kernel keeps a copy of the
< real frames, it will have to keep them *forever* (possibly even
< across reboots), since a user might want to restart his faulted program
< at any time. This puts the burden of storing a possibly infinite number
< of bytes, on the kernel.
For example, on Unix, and program that dies with a bus error is going to
leave a stack frame around in the virtual OS.
It seems to me that the only way to deal with this problem is for Motorola
to publish an algorithm for checking bus error frames, or for people to not
do virtual machines on the 68k series.
Actually, another way would be to make it so that the virtual machine
never gets a bus error, i.e., the virtual machine appears to have it's
full address space full of memory, so that it never has to deal with
a page fault. And if it is an 020, there will be no address errors.
( they did remove alignment requirements, right? it's been a while...).
Then, you only have to deal with long stack frames that are explicitly
built by the OS running under the virtual machine. Simply not allowing
this might not be an unreasonable restriction to place on OS's running
under the virtual system.
--
"Every person who, within any public cemetary or burying-ground, kills, wounds
or traps any bird, or destroys any bird's nest other than swallows' nests, or
removes any eggs or young birds from any nest, is guilty of a misdemeanor"
California Penal Code, section 598 Tim Smith tim@ism780c.isc.comdavet@oakhill.UUCP (Dave Trissel) (11/26/87)
In article <8046@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >< >The generic solution to this is not to let the user's operating system >< >meddle with the frames. Keep the *real* frame somewhere private. Give >< >him a fake one ... >< There is still a real problem here. If the kernel keeps a copy of the >< real frames, it will have to keep them *forever* ... I think there is an easier way out. Think about the reasons for a bus error frame being created in the first place: 1) As an access to currently paged out memory 2) As an illegal access to unassigned memory For case 1 the frame will shortly be referenced again by a RTE as soon as memory is paged in. Thus a virtual machine operating system storing outstanding frame images in a table would find such entries quickly removed. Case 3, on the other hand, would never receive a de-referencing RTE. But how many case 3's are you going to get? They only occur when a process fatally aborts. So the trick is to have a table large enough to sufficiently handle all frames generated during the worst latency of a page-fault recovery. And the illegal access frames slowly fade away into that great bit-bucket in the sky. A virtual O/S capable of running other operating systems can extend this concept by keeping a unique table for each subordinate O/S. The table would simply be saved and restored as part of the subordinate's state if rebooting of the master O/S was required. -- Dave Trissel - Motorola Semiconductor - Austin, Texas ihnp4!ut-sally!im4u!oakhill!davet