This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: Naming schemes for different kinds of virtualization (was Re: [Xen-d

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: Naming schemes for different kinds of virtualization (was Re: [Xen-devel] HYBRID: PV in HVM container)
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Tue, 28 Jun 2011 11:18:37 +0100
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.xen@xxxxxxxxx>
Delivery-date: Tue, 28 Jun 2011 03:19:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTi=1C1szoYe4DqjG4v+EF8NEu2Ee9A@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BANLkTi=1C1szoYe4DqjG4v+EF8NEu2Ee9A@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
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?



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

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>