Re: PVHVM drivers in upstream linux kernel

[Ian Campbell <Ian.Campbell@citrix.com>]

On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
> On 02/12/14 09:39, Juergen Gross wrote:
> > Hi,
> > 
> > looking into the upstream linux sources I realized that the PVHVM
> > drivers of XEN are only available with the pvops kernel. Is this on
> > purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> > configurable without having to enable CONFIG_PARAVIRT?
> 
> I suppose that would be possible but I don't think it's a useful
> configuration because you would lose PV spinlocks for example.

IIRC the reason this hasn't been implemented until now is that
refactoring would be required to the various bits of driver code which
assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
table code. Whether its worth the churn at this stage is debatable, but
I think the (in)ability to use PV spinlocks is a red-herring.

Adding PV drivers to an HVM guest is a useful thing to do, even without
PV spinlocks. PV IO gets you far more incremental benefit than the locks
do, adding PV IO paths is the number 1 thing which should be done to any
guest.

One actual usecase is installing from a distro installer which isn't
PAE, let alone PARAVIRT enabled[0], to get far enough that you can
install a more capable PVHVM kernel with more bells and whistles.

If there were distros around who refused wholesale to enable PARAVIRT
even in a non-default kernel then it would be more likely that they
could be convinced to enable a set of PV IO drivers, since they have 0
impact on a non-PARAVIRT system, and still give significant benefit to
Xen users. I don't know of any of the major distros are refusing
PARAVIRT in this way though.

Ian.

[0] The default i386 Debian installer falls into this camp, but you can
use the special PV Xen variant to install as PVHVM too so it's not so
critical.