Re: OS emulation [was Re: Bootcamp]

In article <mddv7o9ccjg.fsf_-_@panix5.panix.com>,
Rich Alderson  <news@alderson.users.panix.com> 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.