Virtual machines

[Dwight Hughes]

| From: Terrence W. Zellers <zellert@voicenet.com>
|  
  [  snip  ]
| 
|    I'd like to jump in here.  Let me say at the outset that I haven't
| even *looked* at the JVM architecture and know nothing about it save
| passing mentions I've encountered.   But as a more-or-less expert on
| the original real "VM" from IBM I'd like to make a suggestion to
| anyone *thinking* about what an idealized virtual machine should do.

Well, if you would like to see what you are describing here in the JVM,
don't even bother looking! JVM is a miserable excuse for a VM even
in comparison to other "normal" VMs, never mind something like this.
 
|    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
| deals with "real" rather than "virtual" hardware,  and the
| interception and determination of any illegal program state (invalid
| opcode, invalid address, etc).   Admittedly this is not trivial but it
| buys the ability to completely virtualize a process as if it were
| running on "real" hardware.   

Can this be done with an i486 or Pentium? Does it require special
hardware to pull it off properly?

|     This in turn, buys the ability to create an OS which can run
| indefinitely deep under itself. (I've reliable reports from IBM of VM
| running 8 levels deep).  That means that you can test different
| versions of the OS on one live running box.  You can concurrently test
| different versions of the same program.  You can create safe "cells"
| for users to run OS level software without danger of them corrupting
| your "real" OS.  You can create and test software for hardware which
| **doesn't exist on your real system**.
| 
|    As someone who knows VM very well, I'm afraid I'm not communicating
| this very clearly, but it's part and parcel of what I work with every
| day.
| 
|    Anyway there is some discussion of this kind of thing, though not
| as deep or detailed as I hoped it would be on the archive logs of
| FREEVM-L on LISTSERV@clvm.clarkson.edu.  The list is pretty much dead
| I'm afraid, but anyone really interested ought to at least look at
| what the real, honest, original VM has been doing for years.  The
| mainframe may (or maybe not) be dying, but I think the idea of a
| self-idealizing virtual machine is valuable enough to perpetuate.
| 
|       ---------------------------------------------------------
| 
|     I think that in the argot of the present company I'm trying to
| say that the architecture should be such that the OS itself can be
| implemented as an instancable(sic?) object (forgive me, I'm fairly 
| new to OO as well).
| 
|                                                    -- TWZ

Thank you very much for all this information -- this could also make a
great contribution to the LispOS side of this project, perhaps more
than the LispVM side. The ability to self virtualize is one hell of
a security (and reliability) mechanism without weighing everything
down with paranoid security measures down to the lowest level. We
want our system to be fully reflective, but I must admit I had not
thought about it this deeply. Some things we have been looking at
are VMs as first class objects (meaning there could be multiple
completely independent instances of any VM or any number of different
VMs, each would behave as any other object in the system (once no
longer needed the garbage collector would clean it up, encapsulation
from the OS would be automatic, they could be stored, transmitted,...).
We have also considered environments/address spaces as first class
objects. 

I need to find out more on this.

Thanks.

-- Dwight

PS: would you mind if I posted your letter over to the LispOS side?