[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:

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

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_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
- don't skip drivers/xen on make, as XEN might be selected via a
  config item in that directory


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.