Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!netnews
From: af@cs.cmu.edu (Alessandro Forin)
Newsgroups: comp.os.mach
Subject: Re: Mach as a Virtual Machine
Keywords: Mach, Virtual Machine OS
Message-ID: <1991Apr17.043604.20010@cs.cmu.edu>
Date: 17 Apr 91 04:36:04 GMT
References: pmaresch@hal.ulowell.edu (Pierre Mareschal)
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Organization: School of Computer Science, Carnegie Mellon
Lines: 82


> I am trying to answer this question:
> 			"Is Mach a virtual machine software?"

A lovely question, I have centered a talk around it last year.
The way I would quickly summarize my answer is by the following defs:

	@newpage@heading(Virtual Machines and Not)
	
	What is a "Virtual Machine"
	@begin(Itemize)
		"A computing system in which the @i(instructions)
		 issued by a program may be different from those
		 actually executed by the hardware to perform a
		 given task" [opcit-1972, pag 99]
	@end(Itemize)
	
	What is a "Non-Virtual Machine Emulation"
	@begin(Itemize)
		"A computing system capable of providing the same
		 @i(services) as provided by the emulated computing
		 system, with the same interface" [this talk]
	@end(Itemize)
	
	The second definition is less restrictive, @i(services) might include
	@i(instructions).
	
	Since the goal is to run user programs well, the second definition is
	better.

Typically, we use @i(services) in the sense of "Operating System Services",
e.g. same system calls.  The exact definition of such services is however
very much dependent on the particular OS we are emulating.
And so we do "OS emulation", not "Architecture emulation".

> Does the answer depend on the definition of the virtual machine concept?

Definitely.  The definition used by IBM implies instruction emulation, in one
form or another, while the one I used does not.  This has obvious performance
implications: there is no way a system that obeys the first definition can
perform better than the system it is emulating.  As performance measurements
show this is instead quite true of the Unix emulation under Mach.

I have also found there are some severe limitations that derive from the
more restrictive definition, for instance there 'cannot be' interactions
between Virtual Machines in any form other than indirectly through I/O
devices of some kind (e.g. no IPC).  It is instead quite possible that
following the second definition the emulation might provide some new
services [the Mach native syscalls] that indeed allow such interaction.

To further refine the concept:

	@newpage@heading(Operating Systems Emulation)
	
	Any of the following:
	@begin(Itemize)
	Execute programs intended for an Operating System under 
	a different one
	
	Execute an entire Operating System on top of another
	
	Execute multiple Operating Systems on top of a single one

	Execute programs intended for a variety of Operating System
	under the same, different one
	@end(Itemize)

The IBM's approach covers all points, (4) being a consequence of (3).
In Mach we capture esp (1) and (4), but in some cases [e.g. MS-DOS in
virtual 86 mode] even (2).  I do not believe point (3) per-se is of much
value, users just want to run their programs after all.  And the faster
they run the happier they are.


All this being said now there are probably more obvious similarities than
differences in the two approaches, most of the goals being quite similar
after all.  The only *real* difference I feel is the degree of architectural
independence that we are trying to achieve today: back in 67 it was simply
tought/hoped that the 370 would be THE final architecture.
Today we know that the "software" lasts much longer than the "hardware".

sandro-