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
|
Home