Re: Naming schemes for different kinds of virtualization (was Re: [Xen-devel] HYBRID: PV in HVM container)

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 10:29 +0100 on 28 Jun (1309256952), George Dunlap wrote:
> I propose we replace "HVM" with "FV" (for "fully virtualized").  The
> basic difference between FV and PV will be whether the hardware
> platform (motherboard, PCI devices, BIOS, ACPI, e820 map, &c) will be
> emulated or not; or to put it a different way, whether the guest
> kernel knows it's running PV when it boots (and thus doesn't bother
> with BIOS or grub, and always uses hypercalls) or whether it starts on
> emulated hardware and then replaces parts of that when it's running on
> Xen.

That's clear enough, though I doubt any new naming scheme will stop
people using the old ones, especially if we're not willing to s/hvm/fv/g
in the code (which I'm not!).  That being the case it may just lead to
more confusion for newcomers.

> Then we can talk about several modes:
> Fully virtualized: All devices are virtualized; nothing PV.  I propose
> calling this "FV".
> Fully virtualized with PV drivers: Most devices virtualized, but disk
> and network paravirtualized for performance.  "FVD" (+drivers)?  FV+?
> FV1?
> Fully virtualized with PV interrupts: (I.e., Stefano's PV-on-HVM
> series). "FVI" (+interrupts)?  FV++?  FV2?

Aiee!  These are all FV, and the distinction is one of guest kernel
behaviour.  I'm not sure that having a name for, e.g. FV plus
net/block drivers is a useful distinction from that plus time plus
interrupt delivery.

I guess it depends what you see the name being used for.  Among
ourselves, maybe we can use a shorthand.  Most people turning up with
bug reports won't know or care about that distinction; they'll just have
a kernel version + config, and we'll need to see dmesg output anyway.

> Paravirtualized: Classic paravirtualization.  Keep calling this "PV".
> Paravirtualized in an HVM container: What Mukesh has been talking
> about -- same as PV, but using the HVM hardware to gain an extra
> hardware protection level on 64-bit guests.  "PVH"?

If this feature is done well, "PV". :)  There will be no difference
in the guest, just some implementation changes in the hypervisor.

> Paravirtualized with HAP: Same as above, but using the hardware (or
> shadow code) to update pagestables. "PV-HAP"?

Please, no: HAP distinguishes shadow from NPT/EPT.  Is anyone planning
to build this, anyway?  What would be the advantage over FV with a
modern pvops kernel?

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel