[Info-vax] VMWARE/ESXi Linux

[Dan Cross]

In article <vina48$3sjr$6 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 12/3/2024 10:36 AM, Dan Cross wrote:
>> In article <vin68p$3sjr$4 at dont-email.me>,
>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>> On 11/28/2024 8:24 AM, Dan Cross wrote:
>>>> So Goldberg defined two "types" of hypervisor in his
>>>> dissertation: Types 1 and 2.  Of course, this is an over
>>>> simplification, and those of us who work on OSes and hypervisors
>>>> understand that these distinctions are blurry and more on a
>>>> continuum than hard and fast buckets, but to a first order
>>>> approximation these categories are useful.
>>>>
>>>> Roughly, a Type-1 hypervisor is one that runs on the bare metal
>>>> and only supports guests; usually some special guest is
>>>> designated as a trusted "root VM".  Xen, ESXi, and Hyper-V are
>>>> examples of Type-1 hypervisors.
>>>>
>>>> Again, roughly, a Type-2 hypervisor is one that runs in the
>>>> context of an existing operating system, using its services and
>>>> implementation for some of its functionality; examples include
>>>> KVM (they _say_ it's type 1, but that's really not true) and
>>>> PA1050.  Usually with a Type-2 HV you've got a userspace program
>>>> running under the host operating system that provides control
>>>> functionality, device models, and so on.  QEMU is an example of
>>>> such a thing (sometimes, confusingly, this is called the
>>>> hypervisor while the kernel-resident component, is called the
>>>> Virtual Machine Monitor, or VMM), but other examples exist:
>>>> CrosVM, for instance.
>>>
>>> I think the relevant distinction is that type 1 runs in the
>>> kernel while type 2 runs on the kernel.
>
>Reinserted:
># If VSI created a hypervisor as part of VMS then if
># it was in SYS$SYSTEM it would be a type 2 while if it
># was in SYS$LOADABLE_IMAGES it would be a type 1.

Irrelevant; this is based on your misconception of what a type-1
hypervisor is vs a type-2.

>> No.  They both run in supervisor mode.  On x86, this is even
>> necessary; the instructions to enter guest mode are privileged.
>
>That code does something that end up bringing the CPU in
>privileged mode does not make the code part of the kernel.
>
>To build on the VMS example the hypothetical type 2
>hypervisor in SYS$SYSTEM could (if properly authorized)
>call SYS$CMKRNL and do whatever. It would not become
>part of the VMS kernel from that.

This isn't really reelvant.

>Just like VMWare Player or VirtualBox running on Windows
>is not part of the Windows kernel even if they do use CPU
>support for virtualization.

They rely on existing OS services for resource allocation,
scheduling, memory management, etc, which is why they are
type-2 HV's and not type-1.  Xen, Hyper-V, and ESXi implement
those things themselves, which is why they are type-1, and not
type-2.

>> Go back to Goldberg's dissertation; he discusses this at length.

^^^
Read this part again, Arne.

>>> KVM runs in Linux not on Linux. Which makes it type 1.
>> 
>> Nope.  KVM is dependent on Linux at this point.  The claim that
>> it is a type-1 hypervisor is predicated on the idea that it was
>> separable from Linux, but I don't think anyone believes that
>> anymore.
>
>It is the opposite. KVM is type 1 not because it is separable
>from Linux but because it is inseparable from Linux.

Kinda.  The claim is that KVM turns Linux+KVM into a type-1
hypervisor; that is, the entire combination becomes a the HV.
That's sort of a silly distinction, though, since the real
differentiator, defined by Goldberg, is whether or not the VMM
makes use of existing system services, which KVM very much does.

I wrote about this here, at length, several years ago.  C.f.,
https://groups.google.com/g/comp.os.vms/c/nPYz56qulqg/m/vTDtsFNRAgAJ

Perhaps go review that post and read the associated references.

	- Dan C.