pmaresch@hal.ulowell.edu (Pierre Mareschal) (04/16/91)
Hi, I am trying to answer this question: "Is Mach a virtual machine software?" If one think of a virtual machine software as a "software copy of the hardware" [1], the answer is no. Mach provides abstraction of hardware and presents them at the user level, or operating system level. On top of Mach, all hardware looks or appears the same (right?). If a virtual machine is defined as a "system in which the instructions issued by a program may be different from those executed by the hardware to perform a given task" [2]. On another hand, if one think of a virtual machine as a piece of software which allow to run different operating systems in it, the answer can be yes. Mach's designers claim Mach has, or offers the possibility to implement several operating systems on top of it [3-4]. Does the answer depend on the definition of the virtual machine concept? References: [1] R. P. Goldberg: Architecture of virtual machine. Proc. of the Workshop on Virtual Computer Systems, Harvard U., 1972. [2] R. P. Parmelee et al.: Virtual storage and virtual machine concepts. IBM System, Vol. 11, No. 2, 1972, pp. 99-130. [3] R. F. Rashid: Threads of a new system. Unix Review, Vol. 4, August 1986, pp. 37-49. [4] R. F. Rashid et al.: Mach: a foundation for system software. (can't remember where it was published...) -- :- Pierre Mareschal <pmaresch@ulowell.ulowell.edu>
ed@mtxinu.COM (Ed Gould) (04/17/91)
>I am trying to answer this question: > "Is Mach a virtual machine software?" >On another hand, if one think of a virtual machine as a piece of >software which allow to run different operating systems in it, the >answer can be yes. Mach's designers claim Mach has, or offers the >possibility to implement several operating systems on top of it [3-4]. Even in this sense, Mach does not present any more of a "virtual machine" than does any other operating system. The Mach 3.0 facilities don't implement any of the OS *interfaces* that we're currently used to, but they provide a way to implement those interfaces. In that sense, Mach provides a virtual machine. So does every other OS, albeit a different one for each OS. -- Ed Gould No longer formally affiliated with, ed@mtxinu.COM and certainly not speaking for, mt Xinu. "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
af@cs.cmu.edu (Alessandro Forin) (04/17/91)
> 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-
bennett@mp.cs.niu.edu (Scott Bennett) (04/19/91)
In article <1991Apr17.043604.20010@cs.cmu.edu> af@cs.cmu.edu (Alessandro Forin) writes: > >> I am trying to answer this question: >> "Is Mach a virtual machine software?" > [text deleted --SJB] > 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. The above belief about the third goal is out of touch with operational reality. Most shops cannot dedicate an entire machine to the purposes of installing, configuring, testing, and fixing new versions of even the *same* operating system before putting them into production use. Having the ability to run multiple operating systems (or multiple versions thereof) concurrently in the same box is a real blessing to many shops and their budgets. > > [more text deleted --SJB] > >sandro- Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
bennett@mp.cs.niu.edu (Scott Bennett) (04/19/91)
In article <1991Apr17.042700.2568@mtxinu.COM> ed@mtxinu.COM (Ed Gould) writes: >>I am trying to answer this question: > >> "Is Mach a virtual machine software?" > >> [text deleted --SJB] > >Even in this sense, Mach does not present any more of a "virtual >machine" than does any other operating system. The Mach 3.0 >facilities don't implement any of the OS *interfaces* that we're >currently used to, but they provide a way to implement those >interfaces. In that sense, Mach provides a virtual machine. So >does every other OS, albeit a different one for each OS. The above comment makes it obvious that an attempt has been made to make the term "virtual machine" useless by forcing it to to mean things it was never intended to mean. The term *is*, after all, virtual *machine*, *not* virtual operating system interface. A virtual machine is one that looks to a program like a real machine. Even an operating system is supposed to run correctly inside it. Terminology in almost any technical field nowadays is getting to be so voluminous that people new to a field cannot be familiar with all of it. This results in their reinventing or misusing terms. Thanks go to Ed Gould here for putting an end to the nonsense in this case. > >-- >Ed Gould No longer formally affiliated with, >ed@mtxinu.COM and certainly not speaking for, mt Xinu. > >"I'll fight them as a woman, not a lady. I'll fight them as an engineer." Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
af@cs.cmu.edu (Alessandro Forin) (04/20/91)
>> (3) Execute multiple Operating Systems on top of a single one >> >> 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. > > The above belief about the third goal is out of touch with >operational reality. Most shops cannot dedicate an entire machine >to the purposes of installing, configuring, testing, and fixing new >versions of even the *same* operating system before putting them >into production use. Having the ability to run multiple operating >systems (or multiple versions thereof) concurrently in the same box >is a real blessing to many shops and their budgets. The sometimes art-of installing a new version of an OS [e.g relinking the binaries that the manufacturer gives you to adapt the OS to your specific hardware configuration] is certainly of much practical importance, but bears no argument whatsoever on the structural properties of such OS, which is what I was talking about. Point (3) refers to the ability to run "unmodified" OSs binaries on top of each other, not to the ability of running multiple OS emulators and/or multiple versions thereof. Which we do routinely and with much gain. [Practically: IF someone did an IBM V.M. emulator for Mach 3.0 THEN the emulator would do exactly the same things the IBM V.M. does, for system programmers and for anyone else.] >>Even in this sense, Mach does not present any more of a "virtual >>machine" than does any other operating system. The Mach 3.0 >>facilities don't implement any of the OS *interfaces* that we're >>currently used to, but they provide a way to implement those >>interfaces. In that sense, Mach provides a virtual machine. So >>does every other OS, albeit a different one for each OS. Not all OSs let user programs handle their own syscalls/traps, or let users handle virtual memory, scheduling, I/O etc etc the way Mach does. But yes, it is definitely not a Virtual Machine. Would be quite a mistake if it were: I could not be posting from this Mach-Vax, now could I ? ;-) > The above comment makes it obvious that an attempt has been > made to make the term "virtual machine" useless by forcing it to > to mean things it was never intended to mean. The term *is*, after > all, virtual *machine*, *not* virtual operating system interface. > A virtual machine is one that looks to a program like a real machine. > Even an operating system is supposed to run correctly inside it. I think my post was quite clear on this. The term I use is "OS Emulation", which I personally prefer to "OS Environment" or to "OS Personality" because I can give it a more concise technical definition. I could have used "Instruction Set Emulation" to describe what IBM's Virtual Machine concept is based on, but I was afraid of triggering much religious reactions and little more understanding. And besides, it is a bit restrictive in that V.M. must emulate the 370 I/O system as well. > Terminology in almost any technical field nowadays is getting > to be so voluminous that people new to a field cannot be familiar > with all of it. This results in their reinventing or misusing > terms. Thanks go to Ed Gould here for putting an end to the > nonsense in this case. People need new words to understand new things and even new versions of old things sometimes. I do not believe the original poster has attempted in any whatever way to mistreat the V.M. term [he actually had the citation right, remember ?]. It is only natural for someone to inquiry what the difference is between two OSs that appear to do similar things, and wonder perhaps if the new one does it the same way the old one did, or sort-of. Note also that the language community has used the same term "Virtual Machine" extensively for years to denote an hypothetical hardware capable of executing the (intermediate) output of a language compiler. The confusion is perfectly understandable. We all agree Mach is not a Virtual Machine based OS kernel. But we need to be a bit more precise than that to clarify why it can provide to users much of the same functionality. And faster :-)) sandro-
karger@osf.org (Paul A. Karger) (04/24/91)
While several postings have described Mach as not being a virtual machine monitor in sense of VM/370, it most certainly does provide the basic tools for implementing a "hybrid virtual machine system" as defined in Popek and Goldberg's paper, "Formal Requirements for Virtualizable Third Generation Architectures" in the July 1974 issue of CACM. A hybrid virtual machine system allows more instructions to be emulated, rather than directly executed. If you combine that with many modern architectures that, unlike the 360/370, do not specify an I/O architecture, you find that Mach could easily support a VMM and do it more efficiently than a traditional VMM. In particular, if the CPU architecture allows CPU-model dependent I/O interfaces, as the VAX does, then you can define a VMM with an I/O interface that is a set of kernel calls, rather than actual I/O commands on a bus. For an example of such a VMM, see "A VMM Security Kernel for the VAX Architecture" in the Proceedings of the 1990 IEEE Symposium on Research in Security and Privacy. The VMM described there was not based on Mach, but could have been. (I was one of the co-authors of the paper, so I'm quite sure that Mach could easily have supported the system.) The Mach 3.0 microkernel is not a VMM by itself. However with a set of judiciously written servers, it can certainly support a hybrid VMM. Paul
TROTH@RICEVM2.RICE.EDU (Rick Troth) (05/02/91)
When I first caught this discussion, I wanted to say, "No no ... you don't understand what a VM virtual machine is/does.". But now that everyone has defined their terms, it's clear that we all do. VM in fact emulates some instructions that do not exist on native 360/370/390 machines. VM provides the testing-new-releases and the running-different-environments-concurrently aspects Mach offers. It also allows you to run VM on VM, which Mach does not offer. And, of course, Mach offers a number of features VM does not, not the least of which is some sense of portability. :-] I should maybe have changed the subject to "Mach IN a Virtual Machine". I'm in the middle of a research project at Texas A&M to configure a personal UNIX [UNIX is a trademark of ATT] as an alternative to CMS. Mach/370 would certainly be of great use, although I am sure I would not be able to complete implementing it in this go-around. My e-mail tracks led me into IBM research, which has now proven to be a dry gully. [it's gettin' near Summer] If any of you know of a lead to a Mach/370 port, please please tell me. VM offers some interesting possibilities to Mach: if you picture the VM world as a virtual network, you can see one virtual machine acting as the UNIX server, one or more acting as file servers, etc., with user virtual machines serving individual users or small groups. And this virtual network can just as well be "plugged in" to your real network, offering access to/from non-370 machines. -- "The tomb is empty" Rick Troth <TROTH@RICEVM1.RICE.EDU> ------------- Rice ONCS VM Systems Support
troth@rio-grande.rice.edu (Richard M Troth) (05/03/91)
Organization: Rice University, Houston, TX. Date: Wednesday, 1 May 1991 14:40:32 CDT From: Rick Troth <TROTH@RICEVM2.RICE.EDU> Message-ID: <91121.144032TROTH@RICEVM2.RICE.EDU> Newsgroups: comp.os.mach Subject: Re: Mach as a Virtual Machine References: <1991Apr19.180259.18834@cs.cmu.edu> <21336@paperboy.OSF.ORG> When I first caught this discussion, I wanted to say, "No no ... you don't understand what a VM virtual machine is/does.". But now that everyone has defined their terms, it's clear that we all do. VM in fact emulates some instructions that do not exist on native 360/370/390 machines. VM provides the testing-new-releases and the running-different-environments-concurrently aspects Mach offers. It also allows you to run VM on VM, which Mach does not offer. And, of course, Mach offers a number of features VM does not, not the least of which is some sense of portability. :-] I should maybe have changed the subject to "Mach IN a Virtual Machine". I'm in the middle of a research project at Texas A&M to configure a personal UNIX [UNIX is a trademark of ATT] as an alternative to CMS. Mach/370 would certainly be of great use, although I am sure I would not be able to complete implementing it in this go-around. My e-mail tracks led me into IBM research, which has now proven to be a dry gully. [it's gettin' near Summer] If any of you know of a lead to a Mach/370 port, please please tell me. VM offers some interesting possibilities to Mach: if you picture the VM world as a virtual network, you can see one virtual machine acting as the UNIX server, one or more acting as file servers, etc., with user virtual machines serving individual users or small groups. And this virtual network can just as well be "plugged in" to your real network, offering access to/from non-370 machines. -- "The tomb is empty" Rick Troth <TROTH@RICEVM1.RICE.EDU> ------------- Rice ONCS VM Systems Support
af@cs.cmu.edu (Alessandro Forin) (05/03/91)
> It also allows you to run VM on VM, which Mach does not offer.
Mach traps can be redirected to user space just like any other trap.
There is one trap (htg_mach_syscall) that allows you to invoke the
others even if they are redirected ==> Mach on Mach is trivial :-))
Much more interesting is the work that is being done for Norma-Mach,
which also involves "emulating" various Mach kernel services in user space.
sandro-