[Info-vax] clock problems with OpenVMS x86 on VirtualBox

[Dan Cross]

In article <u43ra1$13to$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 5/15/2023 4:47 PM, Dan Cross wrote:
>> In article <u3tv4e$34ma3$1 at dont-email.me>,
>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>> The hypervisor is there.
>>>
>>> But no host OS.
>> 
>> For all intents and purposes, the hypervisor _is_ the host OS.
>> Some software component must drive the hardware, run VCPUs, etc:
>> that's the hypervisor.
>
>A hypervisor is not a host OS.

This is an odd thing to say; see my other response in this
thread, but a "Type-1" hypervisor very much meets most
reasonable definitions of an "operating system."  For example,
taking Roscoe's definition that I mentioned earlier:

"The operating system is that body of software that:
- Multiplexes the machine's hardware resources,
- Abstracts the hardware platform,
- Protects software principals from each other,
(using the hardware)"
(https://www.usenix.org/conference/osdi21/presentation/fri-keynote)

A hypervisor certainly qualifies based on these criteria, as I
again mentioned elsewhere in this thread.  I will agree that
this is not a _general purpose_ operating system, but to assert
that it is not an operating system is simply incorrect.

>Not in terminology and not in functionality.
>
>The stacks are:
>
>guest OS
>type 1 hypervisor
>hardware
>
>and:
>
>guest OS
>type 2 hypervisor
>host OS
>hardware

This is a overly simplistic take, and not reflective of actual
implementation or practice.

Every extact "type-2" hypervisor in common use today has a
significant kernel-resident component that runs _as part of_ the
host OS; indeed, entry to a VM using both VMX and SVM on x86
requires execution of privileged instructions, and exit from the
VM context is always in ring0.

Consider Bhyve, for example: it is firmly in the "type-2" camp,
yet has a substantial kernel-resident VMM component that goes as
far as implementing several non-trivial device models (the PIC,
PIT, etc).  This all runs "on the bare hardware."

>Host OS and hypervisors are terms used for different things.
>
>And used for things that provide different functionality:
>
>a host OS is a normal OS like Linux or Windows able to run
>applications in general including but certainly not limited
>to type 2 hypervisors

You seem to be conflating the idea of the operating system as
the body of software that drives the hardware and mediates
access to resources while providing abstractions for software,
with a general purpose operating system such as VMS or Unix.

>a type 1 hypervisor like VMWare ESXi is a special piece of
>software able to run VM's and partition the hardware resources
>between the VM's - usually they are extremely thin and with only
>this very specialized functionality - any heavy stuff
>are usually put elsewhere in a VM (often known as a Dom0
>VM) or a remote management application

You seem to be repeating things I've already said in this thread
regarding the root VM/remote control plane.  For example, I said
more or less exactly this on May 15:
https://groups.google.com/g/comp.os.vms/c/nPYz56qulqg/m/Es3OgP_PCAAJ

Regardless, your characterization of e.g. ESXi is simply wrong.
Engineers I personally know who either have or do work in that
codebase acknowledge that it is a rather complex operating
system in its own right.  Or consider Xen, which is another
type-1 hypervisor: we can actually examine its code, as it is
open source; it's hardly what you are describing it as.

>a type 2 hypervisor like VMWare Player is an application running
>on a host OS that runs a VM

This is only partially correct.  In order to drive the
virtualization extensions provided by the hardware, these
applications _must_ have a kernel component: that is how the
hardware works.

>> The arbitrary distinction between "Type-1" and "Type-2" style
>> hypervisors is also a bit illusory among those who work on them;
>> like all approximations, it is just that.
>
>Anyone that works with them will know the difference between type
>1 and type 2 (and the difference between a hypervisor and a host OS).

Let's go back to Goldberg's original definitions from his 1972
dissertation, where the terms were introduced:

>From https://apps.dtic.mil/sti/citations/AD0772809:
| Type I vs Type II VMM
|
| The implementation requirement specifies that most VCS
| instructions execute directly on the host.  It does not
| indicate how the VMM 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 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 VCS categories arise:
|
| Type I--The VMM runs on a bare machine.
| Type II--The VMM runs under on an extended host, under
| the host operating system.
|
| In either case, the virtual machine being created is
| equivalent to the bare host or a related family member.
|
| Type I (bare host) and Type II (extended host) VCS's are
| illustrated in figure 2-4.  In both Type I and Type II VCS,
| the VMM crates the VCS environment.  However, in a Type I
| VCS, the VMM on a bare machine must perform the system's
| scheduling and (real) resource allocation.  Thus, the Type I
| VMM may include much code not specifically needed for a VCS.
| In a Type II VCS, the resource allocation and environment
| creation functions are more clearly split.  The operating
| system does the normal system resource allocation and
| provides a standard extended machine environment.  The VMM
| program runs on the extended machine environment and produces
| a pseudo-hardware environment.
(Note: VCS here is "Virtual Computer System")

Now, in particular, Bugnion, Nieh and Tsafir noted that these
definitons are primarily concerned with resource allocation, and
that Goldberg assumed both types would execute with full
supervisor privileges over the machine. (Edouard Bugnion,
Jason Nieh, and Dan Tsafir: "Hardware and Software Support for
Virtualization". 2017; Morgan and Claypool.)

But note specifically where Goldberg says that a type-1
hypervisor must take on many of the functions of a traditional
operating system with respect to scheduling and resource
management; or as he put it: "Thus, the Type I VMM may include
*much code not specifically needed for a VCS*."  Indeed, nothing
here suggests that a "Type-1" hypervisor cannot provide, say, a
filesystem for the division of storage resources between VMs.

For those who work on the implementation of these systems, we
must ask ourselves, what do these distinctions actually _mean_?
KVM bills itself as turning Linux into a type-1 hypervisor, and
it obviously makes heavy use existing kernel primitives (VCPUs
are associated with tasks, for example), yet it is entirely
kernel resident (interactions with KVM are via ioctls).
Similarly, the engineers working on ESXi acknowledge that it is
actually an operating system under the hood, with complex
interactions with storage devices, networks, a management plane,
etc.  Then we get to things like Dune or gVisor, which are much
closer in spirit to what Goldberg described as a "type-2"
hypervisor, where they make use of the virtualization hardware
and provide an OS abstraction to an application.
https://web.stanford.edu/group/mast/cgi-bin/drupal/content/dune-safe-user-level-access-privileged-cpu-features
https://gvisor.dev/

Contextually, Goldberg was writing in an environment where
computers were physically large and expensive; the distinction
he wanted to make was whether the machine would be
simultaneously serving users running jobs along with VMs on the
same host, of users would be interacting only with VMs.  In that
context, what does it mean in the modern era where a machine in
a rack in a datacenter _may_ be running a "type-2" hypervisor
but never run anything other than VMs and a thin management
plane?  This would de-facto meet Goldberg's type-1 criteria,
despite the archtecture of the overall system.  And Goldberg
himself acknowledged that a type-1 hypervisor would necessarily
take on many of the functions of a host OS.  So no, these lines
are a lot blearier than the naive interpretation.

>It is not an approximation. It is distinct as the difference
>between 3 and 4.

Nope.

At the end of the day, modern hypervisors do not fit into neat
little categories defined in 1972, either in implementation or
practice.

	- Dan C.