Date: Wed, 12 Nov 1997 19:32:55 -0400 From: Richard Costine <rjc@n2k.com> To: hackers@FreeBSD.ORG Cc: ejs@bfd.com, gad@eclipse.its.rpi.edu Subject: Re: Virtual Intel Machines? Message-ID: <346A3CA7.237C228A@n2k.com>
next in thread | raw e-mail | index | archive | help
I'm an old VM'er myself, and often wondered about this. From what I remember, VM did (does) run virtual machine code on the real machine until a privop is encountered. It does make the distinction between Virtual supervisor state and Virtual user (problem) state. There's also Real supervisor state and a real problem state. Unless things have changed, CMS (the loose equivalent of VM's shell) always runs in supervisor state under a virtual machine. Virtual machines run in real problem state. The nucleus or VM's kernel code runs in real supervisor state. So, when the CMS "operating system" makes a system call (in Mainframe lingo - an SVC) control is transferred to a subroutine that runs in the Virtual Address space of that virtual machine by the "real" VM operating system. There are ways to "talk" to the actual underlying emulator, or VM nucleus. The way you do it is by using the "Diagnose" instruction - a real 370 instruction (X'83'). On the real machine, "Diagnose" is the garbage can of instructions - it's hardware dependent. If run "virtually", it effects a "hypervisor" call, which doesn't generate a privileged operation execption in the virtual machine because the virtual machine is a "process" running in real problem state and is virtually allowed to run virtual privileged operations, and the diagnose instruction is run. However, when this happens the "real" privop exception handler gets invoked and the diagnose instruction is handled by a subroutine in the VM nucleus (or kernel). Virtual diagnoses are used for lots of things, block reading of minidisks, VMCF and IUCV (akin to message queues in Unix), getting the VM OS Level, Virtual console handling - there's lots of 'em. There's somewhat more to it than that, there's different classes of users (A-Z) and unlike unix, a user (virtual machine) can only log on once. Different classes can do different "diagnoses" and "cp" commands (which are done by a "diagnose 8"). Classes are not inclusive - that is class F users may be able to to things that Class A users can't, but generally lower letters (A,B,C) give you the equivalent of superuser, but I digress. Given the way Intel has designed its architecture, I agree that you couldn't do it exactly the way that VM is doing it. You would have to emulate everything. That is you would need to write a program that simulates an Intel 486/Pentium/Pentium-pro architecture. The opcodes that work differently in the non-privileged state would need to be emulated so as to produce a virtual trap, that is the emulation software would simulate the trap. This would make the emulator much slower than a real pentium, but with the speed of today's processors, now in the 200MhZ range, it may be able to simulate at least to the speed of a 50Mhz 486 or even a low speed pentium (75MHz). Yes, this would be a "Nice Thing to Have". It opens up lots of possibilities. You could have a real sandbox to run intel-based code in. We all know there's lots of that about. You could run Windows 95 or even NT under FreeBSD (you would need a copy of those operating systems), kind of like "DOSEMU". You could bring up the next version of freebsd under freebsd. You could perhaps (if you run multiple emulators on the same box) simulate a network of PCs all with virtual ethernet cards. Are you afraid of running that latest ".exe" file that someone sent you? Fire up the emulator with your basic Windows 95 "C" disk junk on a "minidisk" - run the .exe file they sent. If it is virused, you'll booger up the virtual environment. Who cares? Blow it away after you're done - you have a copy of the "minidisk" (which is merely a file on freebsd) somewhere to use for another emulaed session. The point is not how fast it'll run but *that* it'll run. > From: "Eric J. Schwertfeger" <ejs@bfd.com> > Date: Wed, 12 Nov 1997 08:45:20 -0800 (PST) > Subject: Re: Virtual Intel Machines? > To: gad@eclipse.its.rpi.edu > Cc: hackers@FreeBSD.ORG > > On Wed, 12 Nov 1997, Garance A Drosehn wrote: > > > In the land of IBM mainframes, there's an operating system (of > > sorts) called VM. This is an operating system which lets you run > > multiple operating systems on a single machine, at the same time. > > VM can allocate devices between the running systems, so that one > > running OS sees a given hard disk (for example), but no other > > operating systems can possibly get to that hard disk. > > > > What I was wondering is if something similar could be done with > > Intel-ish chips? I realize this wouldn't be a trivial thing to > > write, but it'd be mighty convenient to have in some circumstances > > (at least in an academic setting). > > Not in the strictest sense, because Intel, in their infinite wisdom, > decided that certain privledged instructions, if executed in an > unprivledged state, would not trap, but rather reduce to a NOP. Hence, > the VM equiv can't trap the OS's attempt to do this, and make it happen, > given appropriate permissions.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346A3CA7.237C228A>