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

On Tue, Jun 28, 2011 at 8:46 AM, Keir Fraser <keir.xen@gmail.com> wrote:
> Well, maybe. But we now have HVM guests, PV guests, and PV-HVM guests.
I''m
> not sure that adding explicitly HVM-PV guests as well isn''t just a
bloody
> mess.
Speaking of which, it might be a good idea to have an open discussion
at some point about the naming scheme we use for all these varieties.
The biggest confusion, i think is that "HVM" currently implies not
only the hardware technology, but also the fact that there''s almost a
fully emulated platform (motherboard, BIOS, PCI devices, &c).  And
it''s not obvious at first how different "PV-on-HVM" (i.e.,
mostly
virtualized but using PV interrupts) and "PV in an HVM container"
(i.e,. mostly PV but just using HVM

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.

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?

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

Any thoughts / preferences?

 -George

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

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@citrix.com>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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