Re: [Xen-devel] PVHVM drivers in upstream linux kernel

[Juergen Gross <jgross@xxxxxxxx>]

On 12/02/2014 12:05 PM, Ian Campbell wrote:
> 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.
I take this as an "ack" to change this. :-)

> 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.
I think we have customers wanting to run a default kernel as domU. So it
isn't always the distro refusing paravirt, it might be the user...

Okay, how do the current config settings regarding Xen look like?

We have:
- XEN depending on PARAVIRT
- XEN_DOM0 depending on XEN and others
- XEN_BACKEND depending on XEN_DOM0
- various backend drivers depending on XEN_BACKEND
- XEN_PVHVM depending on XEN
- various frontend drivers depending on XEN (even if some are not
  depending on XEN according to Kconfig, they do as the complete
  drivers/xen directory is made only if CONFIG_XEN is defined)

To sort things out I'd suggest to:
- make XEN independent from PARAVIRT
- let XEN_DOM0 select XEN_BACKEND, PARAVIRT, XEN
- let XEN_BACKEND select PARAVIRT, XEN (I'd like to be able to build
  a driver domain without XEN_DOM0)
- introduce XEN_FRONTEND, let it select XEN
- let frontend drivers and drivers needed by those depend on
  XEN_FRONTEND
- let XEN_PVHVM select XEN_FRONTEND
- don't skip drivers/xen on make, as XEN might be selected via a
  config item in that directory


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel