Re: Not-so-symmetrical SMP?

Wayne Schlitt (wayne@backbone.midwestcs.com)
12 May 1997 23:58:38 -0500


In <m0wPDPl-0005FHC@lightning.swansea.linux.org.uk> alan@lxorguk.ukuu.org.uk (Alan Cox) writes:

>
> > tells you about the supervisor state much be trappable, but in order
> > to create a _usable_ VM, you need much more than that.
> >
> > Any instruction that may cause I/O to be performed _must_ be
> > trappable. Any timing requirements must be able to be emulated
> > precisely.
>
> Umm.. not in general. Yes a tiny number of dodgy mac copyprotection
> floppies might not work. The trapping of memory I/O itself is easy
> the MMU does it nicely

The problem is not with copy protection, the problem is with "buggy"
hardware which requires things like four back-to-back writes to an I/O
port, or it will wedge, or pick up garbage off the bus, or assume
zeros, or what not. The problem is also with trying to decide when
you see the first byte written to an I/O port whether to let the
entire I/O process go through. The problem is also with having to
know how to translate DMA addresses from the virtual machines "real"
memory to the real, real memory while the bytes are being written
out. These are not always very easy things to do, and some are down
right impossible to handle.

> > Virtual memory must also be emulated. This means that any time the
> > virtual machine modifies a page table, the hypervisor must be able to
> > check that it is correct and be able to modify the real page tables
> > correctly. On every time slice, you must update the real page tables
>
> The 680x0 caches its MMU tables quite aggressively so you really only
> have to watch people cycling MMU registers to tune the tables. The dirty
> bit on their 'notional' page tables tells you which ones they
> fiddled with.

Yes, this is possible to do without hardware assist, it just gets very
time consuming. There is a lot of checking that has to be done and it
has to be done at every context switch.

> > In short, I can't see anyway that a 68030 can "exactly emulate a 68030
> > at almost normal speed". I don't think you can come close. I
>
> Lets put this in perspective - you can do a 68040@25MHz in software on a
> 486DX4/100...

This is a very specific claim. I have heard of no one doing a
complete 68k virtual machine for anything other than "toy"
simulations. Where did you get this info from?

> For worst cases you are right, for most real 68K boxes and especially stuff
> like MacOS which doesnt bash the MMU very hard I think we can indeed get
> very very close. Certainly I think I can do very well on the MacOS on MacLinux
> problem in the end - I can even tell the MacOS it doesnt have an MMU and let
> it run the 24bit wired mappings on a standard MacII..

Well, yes, if you restrict things so that the "virtual machine" is no
longer a virtual 68k, things get much easier.

You also lose all the really neat ablilities of a virtual machine,
such as being able to debug/monitor your complex OS (like Linux) while
running under your virtual machine, or not having to write dozens of
"OS emulators" for each OS that you want to run an application under,
or testing a "20-way SMP" on a single processor, or testing a "200
machine network" on a single processor, or....

-wayne

-- 
Wayne Schlitt can not assert the truth of all statements in this
article and still be consistent.