Virtual machines

[James P White]

At 07:59 PM 5/22/97 +0000, Terrence W. Zellers wrote:
>.> >> | From: Terrence W. Zellers <zellert@voicenet.com>
>> >> |  
>> >> |    IMO it ***MUST*** be capable of fully virtualizing itself in
>> >> | execution, not just emulation.   This means it must have a
>> >> paging | prefix algorithm, the ability to intercept any
>> >> instructions which
>
>.> >    The x86 architecture is NOT self virtualizable, no, but we're
>> >discussing an idealized VM to be emulated.  That can be done, of
>> >course, though at greater overhead than true on virtualizable
>> >hardware. A fair amount of the FREEVM discussion touched on that.
>> 
>
>Jim replied:
>> The x86 VM (386 and up) *is* self virtualizable using exactly the
>> same techniques as the IBM VM architecture (memory and i/o
>> mapping/paging/trapping, exception trapping and emulation, privilege
>> limits/exceptions).
>
>Are you certain?   I haven't studied the matter but I've been told
>that the 32 bit implementations can virtualize the 16 bit instruction
>sets ('86, '186, '286) but that they cannot fully virtualize themselves.

The full instruction set is available in virtual mode.

>> It is interesting to note that, AFAIK, no commercial OS for the x86
>> bothers to support self virtual operation.  They all use it for
>> security sandboxes.
>
>We'd be whistling away building fVM if we had a hint of a clue that
>it was possible on an x86 platform.  Basically it was the perception
>that a requisite intermediate emulation layer (architecture unspecified)
>would make the project too big, (and the resulting platform too slow)
>to make it worth doing.  If someone who understands what *complete*
>self virtualization means can tell me that it *is*  possible (Hmm,
>the description of PUSHFD doesn't say anything about throwing an
>interrupt - ie a guest can determine his state without the supervisor
>being able to fake him out; doesn't look virtualizable to me) I'll 
>have to dig into the x86 architecture in detail myself - something I 
>have a kind of minor perverse pride in having avoided these many 
>years ;-) 

PUSHFD does provide a hole in the virtualization mechanism that allows a
program to prevent itself from being virtual.  This was an issue with the
386, I don't recall what, if anything, the 486 or Pentium did about that.
Certainly a minor flaw compared to an architecture that does not permit
virtualization.

>But you folks seem willing to tackle the project despite the 
>emulation thang - or more properly because of the prospect of
>universality of application.   More power to you!  I'm just 
>suggesting a property for your idealized architecture. 

I agree self virtualization is a good thing for the VM to do.  I also
pointed out that the JVM does provide that to a large extent.  The question
I had was what VM controls are needed beyond those that the JVM provides
(hardware/system resources and threads).  

The debug classes (sun.tools.debug) provide full control of instruction
execution.  Should those be part of the VM?  

What sort, if any, of additional control should we have over object memory
allocation?

Jim
-----------------------------------------------------------------------
James P. White                        Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
jim@pagesmiths.com        Pagesmiths' home is http://www.pagesmiths.com