Re: PVHVM drivers in upstream linux kernel

[Juergen Gross <jgross@suse.com>]

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