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:39:05 +0100 Message-ID: <547DA4D9.2060206@suse.com> References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com> <1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com> <1417520175.24320.13.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: <1417520175.24320.13.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 Cc: "xen-devel@lists.xensource.com" , David Vrabel List-Id: xen-devel@lists.xenproject.org On 12/02/2014 12:36 PM, Ian Campbell wrote: > On Tue, 2014-12-02 at 12:33 +0100, Juergen Gross wrote: >> 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. :-) > > It's a best "IMHO being able to do this is a useful thing". I can't ack > the actual final patch, a) I'm not a relevant maintainer and b) I've not > seen the patch. It was not meant to be taken as an ack for a not yet written patch. :-) > >> Okay, how do the current config settings regarding Xen look like? > > ...I'll leave the mechanics down to you and the maintainers to thrash > out. Yeah, stay tuned. :-) Juergen