From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   Rich Alderson   wrote:   
   >cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >   
   >Too many levels to be certain who actually wrote the following quoted by Dan:   
      
   Arne wrote that part.   
      
   >>[snip]   
   >> Consider PA1050 on TOPS-20, for example: this was a type-2 hypervisor that   
   >> allowed the DECSYSTEM-20 to provide very faithful emulation of TOPS-10.  But   
   >> TOPS-20 is argably closer to TOPS-10 than, say, VMS is to Linux.   
   >   
   >Boggle.   
   >   
   >Tops-10 and TENEX/TOPS-20 run on the same base hardware (the PDP-10), and   
   >TOPS-20 shares part of its name with Tops-10, but other than that they are   
   >entirely unrelated.   
      
   I will definitely defer to you on the specifics, Rich, but I   
   should also take my own advice and qualify what I wrote...or at   
   least attempt to explain it better.   
      
   What I meant was that, as the machines that both TOPS-10 and   
   TOPS-20 ran on, were so much more constrained, and the two   
   systems so much smaller, that even though they were (as you   
   rightly point out) unrelated, the differences were necessarily   
   smaller simply because the total surface area of the two systems   
   was so much smaller than either (modern) VMS or Linux.   
      
   >PA1050 (which was written by the BBN folks who created TENEX, the ancestor of   
   >TOPS-20), emulates a subset of the system calls of Tops-10, in order to allow   
   >utilities like the FORTRAN and COBOL compilers to run on an OS for which they   
   >were not engineered.  It does this by mapping a set of routines into the user   
   >program which then make TOPS-20 system calls invisibly.  These routines are   
   >mapped in when the first Tops-10 system call (which is in essence an illegal   
   >instruction that thereby triggers a trap to the monitor) is encountered in the   
   >user program instruction stream.   
   >   
   >PA1050 is, in this sense, not a hypervisor but something equivalent to the   
   Wine   
   >emulator on Linux ("Wine Is Not an Emulator", indeed).   
      
   I'm going to disagree here.  This is almost exactly the   
   definition of a type-2 "trap and emulate" hypervisor, a la   
   Goldberg's original.   
      
   I've posted this before, but for reference, here's Goldberg's   
   definition, as edited to update terminology by Bugnion et al:   
      
   |The implementation requirement specifies that instructions   
   |execute directly on the host. It does not indicate how the   
   |hypervisor gains control for that subset of instructions that   
   |must be interpreted. This may be done either by a program   
   |running on the bare host machine or by a program running under   
   |some operating system on the host machine.  In the case of   
   |running under an operating system, the host operating system   
   |primitives may be used to simplify writing the virtual machine   
   |monitor.  Thus, two additional VMM categories arise:   
   |   
   | * type-1: the VMM runs on a bare machine,   
   | * type-2: the VMM runs on an extended host, under the host   
   |   operating system   
   |   
   |[...] In both type-1 and type-2 VMM, the VMM creates the   
   |virtual machine.  However, in a type-1 environment, the VMM on   
   |a bare machine must perform the system's scheduling and (real)   
   |resource allocation.  Thus, the type-1 VMM may include such   
   |code not specifically needed for virtualization.  In a type-2   
   |system, the resource allocation and environment creation   
   |functions for virtual machine are more clearly split.  The   
   |operating system does the normal system resource allocation and   
   |provides a standard extended machine.   
      
   With respect to "WINE", I suspect that the "emulator" they're   
   referring to code/instruction emulation at the hardware level,   
   not emulating the system interface.  The terminology here is   
   unfortunately somewhat ambiguous, but I imagine they were trying   
   to contrast with Wabi, which did do hardware emulation (it   
   originally ran on SPARC).   
      
   >> And since TOPS-20 used a different mechanism for trapping into the executive   
   >> for system requests than TOPS-10, it was easy to distinguish between the   
   two.   
   >   
   >At the base level, no, it does not.  It simply uses a different "illegal"   
   >instruction to trigger the context switch from user mode to monitor mode than   
   >does Tops-10.   
      
   Well, picking a different instruction is certainly a different   
   mechanism, and is what I meant.  The point is that whatever is   
   handling the trap in the monitor can look at how it was entered   
   to determine how to respond.   
      
   >> On the other hand, things like gVisor, which emulates the Linux   
   >> kernel interface, are very complex and difficult to get right.   
   >> And of course the PDP-10 was a much simpler machine than x86_64.   
   >   
   >Agreed.   
      
   And to be clear, I consider gVisor a hypervisor, as well.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)