From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: PVHVM drivers in upstream linux kernel Date: Tue, 02 Dec 2014 12:33:38 +0100 Message-ID: <547DA392.90701@suse.com> References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com> <1417518314.24320.9.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1417518314.24320.9.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , David Vrabel Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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