>: >It was designed to have complete control of the hardware resources,
>: >not to be at the mercy of willy-nilly windoze GPFs, crashes and lockups!
>: Funny, that's *exactly* what a lot of people said when multiple
>: DOS sessions under Windows first became possible. ;-)
>Exactly. There is such a thing as a virtual machine.
>On the other hand, there's no way Win95 is going to hand over ring 0
>privs on the machine. And I don't think a x386 has a virtual-386 mode :)
>Same problems with Win95 under Linux, of course.
>I believe our only options are to either flakify Linux to not
>require as many privs as it does (which sounds to un-knowledgable
>me a very very significant rewrite), or to wait for the
>64-bit line of x86 processors to come out, which will of
>course have virtual 386 mode :) (and still a virtual 8086 mode? horrors!)
How about this then. The main os (ie that which get booted after power on
or reset) has total control of the machine. The guest os (that which is to
be run as a guest under the main os) is then booted. Since it only has the
normal process rights, when it tries to do something protected it will cause
some sort of trap into the main os, which can emulate what the guest is trying
to do and then allow the guest to continue, blissfully unaware that it is not
really in control.
Wasn't this how IBM's VM operating system worked? Amdahl's UTS (Unix) could
be run as guest under VM. You set up a virtual machine that defined the mapping
of physical resources to virtual and then configured the guest to use the
virtual resources. When it tried to do some I/O to the virtual disk device
it would causes a privellege violation. VM would do the virtual/physical
translation and do the I/O to the real disk. Upon completion it would
simulate an interrupt (virtual) to the UTS kernel.
There was, of course, considerable overhead in all this.
Did anyone ever do a VM/386 for the PC? it should be possible, given some
work on the kernel to do this under linux.
Jo Stockley "Neccessity is the Mother of Invention...