On Tue, Jun 28, 2011 at 8:46 AM, Keir Fraser <keir.xen@xxxxxxxxx> 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
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
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+?
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?
Xen-devel mailing list