From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: IA64 Self Virtualizable?
Date: 19 Nov 1997 02:33:38 GMT

In article <3470A482.CD1229E3@cs.wisc.edu>, Andy Glew <glew@cs.wisc.edu>
writes:

|> Exactly why would you find self-virtualizability making device driver
|> development easier?
|>
|> I don't know about Merced, but I know that we talked about doing a fully
|> self-virtualizing x86, and always end up not doing it because there do
|> not seem to be enough good reasons.
|>
|> I think John Mashey posted something saying that virtual machines were
|> never on MIPS' highly ranked feature list, as well.
|>
|> Making device driver development easier sounds important. And I bet that
|> all you mean is that

1) Correct.  Self-virtualizing was *never* on MIPS' list of features,
and not by omission, but on purpose.

2) The last time this came up, I think I pointed out the salient differences,
but I can't find that post, so I'll try again.

Production self-virtualizing machines (or at least, ones in which you'd
actually run a real OS underneath a hypervisor) are encouraged by:
	1. High system cost, as in mainframes.
	   For years, many sites only had one (1), or maybe a big one
	   and a smaller one for development.
	2. Low unit count, as in mainframes (for new-system testing)
	   For years, many sites only had one (1), or maybe a big one
           and a smaller one for development.Badly placed ()'s
	3. Appropriateness of instruction set, i.e., easy to trap
	   and emulate privileged operations
	4. Appropriateness of I/O, i.e., SIO+CCW chains are much easier to
	  do at a reasonable rate than having to trap individual loads and
	  stores to memory-mapped I/O devices.
IBM mainframes had all of these properties, plus (and maybe some IBMer
will correct/amplify the following opinion: it always seemed that
VM/CMS got at least a big a boost in usage from CMS (which of course,
was written to be an interactive system that *knew* it had a hypervisor
underneath, and didn't run on raw iron) as from the possibilities of running
the batch OS's on VM, and that happened because TSS didn't really take off,
and TSO wasn't all that people might have liked.  The overall usefullness
induced IBM and others to keep evolving the hardware for better
virtualization of OSs.

(1) Minis and micros can actually be expensive, but there have usually been
low-cost ones, taking away much of the system programmer's motivation,
and also, (2) allowing people to buy several systems, and test out new OSs
at a lower cost.  (3) Instruction sets may or may not be appropriate
(MIPS is actually pretty reasonable), but the killer problem, especially
for device driver work, is (4) I/O structure.

	For those unfamiliar with S/370 I/O, the OS:
	(1) Sets up a list of Channel Command Words in memory, which can
	be fairly long, and are intended as programs for an I/O channel,
	each of which could be as complex as the simpler S/370 CPUs.
	These contined commands plus DMA addresses & lengths.
	(2) The I/O is initiated by some kind of Start I/O, a privileged
	operation.

	(3) A hypervisor easily traps the SIO, and can then can translate
	most of the CCWs directly (later CPUs had extra hardware that helped),
	changing addresses, splitting transfers that crossed pages, etc.
	(Some I/OS used self-modifying CCW chains, i.e., you'd have a CCW that
	read data from disk, then jumped to a CCW attached to the data,
	which then read in another block, etc, for loading code quick.)

Since early micros, themselves, were simpler devices than (say) an IBM
Block Multiplexor channel, and since many (not all of course) used
memory-mapped I/O, a device driver has
numerous stores and loads to addresses that must be trapped,
decoded, translated, and interpreted individually ... or else you just
have to trap, and then go to interpretation for large amounts of code,
and the interpreter has to watch out for I/O addresses.
[MIPS long used an interpreter like this, SABLE, for debugging,
but it just isn't very fast.]

Finally, most of the micros grew up with interactive OSs from an
early age, hence didn't get the "boost" like CMS added.

Anyway, people usually focus on the ISA, especially the interrupt/privileged
operations/TLB, etc ... but I'd claim the real inhibitors are the different
style of I/O, and the lower cost.  Of course, as some I/O devices get
smarter, and interactions with them start to look more like CCWs,
maybe this changes ... but it's probably too late.




--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-932-3090
USPS:   Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389