From: cross@spitfire.i.gajendra.net
In article ,
Arne Vajhøj wrote:
>On 12/3/2024 10:36 AM, Dan Cross wrote:
>> In article ,
>> Arne Vajhøj 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.
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
