From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: RFC: xen config changes v4 Date: Fri, 27 Feb 2015 10:04:18 +0000 Message-ID: <1425031458.14641.130.camel@citrix.com> References: <20150226015305.GE8749@wotan.suse.de> <54EEA847.6070505@suse.com> <54EEF0A7.6060804@citrix.com> <20150226172925.GL8749@wotan.suse.de> <20150226184813.GN8749@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YRHoV-0007SA-IQ for xen-devel@lists.xenproject.org; Fri, 27 Feb 2015 10:06:31 +0000 In-Reply-To: <20150226184813.GN8749@wotan.suse.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Luis R. Rodriguez" Cc: Juergen Gross , Stefano Stabellini , David Vrabel , Jan Beulich , xen-devel@lists.xenproject.org, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On Thu, 2015-02-26 at 19:48 +0100, Luis R. Rodriguez wrote: > On Thu, Feb 26, 2015 at 05:42:57PM +0000, Stefano Stabellini wrote: > > On Thu, 26 Feb 2015, Luis R. Rodriguez wrote: > > > On Thu, Feb 26, 2015 at 11:08:20AM +0000, Stefano Stabellini wrote: > > > > On Thu, 26 Feb 2015, David Vrabel wrote: > > > > > On 26/02/15 04:59, Juergen Gross wrote: > > > > > > > > > > > > So we are again in the situation that pv-drivers always imply the pvops > > > > > > kernel (PARAVIRT selected). I started the whole Kconfig rework to > > > > > > eliminate this dependency. > > > > > > > > > > Yes. Can you produce a series that just addresses this one issue. > > > > > > > > > > In the absence of any concrete requirement for this big Kconfig reorg I > > > > > I don't think it is helpful. > > > > > > > > I clearly missed some context as I didn't realize that this was the > > > > intended goal. Why do we want this? Please explain as it won't come > > > > for free. > > > > > > > > > > > > We have a few PV interfaces for HVM guests that need PARAVIRT in Linux > > > > in order to be used, for example pv_time_ops and HVMOP_pagetable_dying. > > > > They are critical performance improvements and from the interface > > > > perspective, small enough that doesn't make much sense having a separate > > > > KConfig option for them. > > > > > > > > > > > > In order to reach the goal above we necessarily need to introduce a > > > > differentiation in terms of PV on HVM guests in Linux: > > > > > > > > 1) basic guests with PV network, disk, etc but no PV timers, no > > > > HVMOP_pagetable_dying, no PV IPIs > > > > 2) full PV on HVM guests that have PV network, disk, timers, > > > > HVMOP_pagetable_dying, PV IPIs and anything else that makes sense. > > > > > > > > 2) is much faster than 1) on Xen and 2) is only a tiny bit slower than > > > > 1) on native x86 > > > > > > Also don't we shove 2) down hvm guests right now? Even when everything is > > > built in I do not see how we opt out for HVM for 1) at run time right now. > > > > > > If this is true then the question of motivation for this becomes even > > > stronger I think. > > > > Yes, indeed there is no way to do 1) at the moment. And for good > > reasons, see above. > > OK if the goal is to be able to build front end drivers by avoiding building > PARAVIRT / PARAVIRT_CLOCK and if the gains to be able to do so (which haven't > been stated other than just the ability to do so) are small (as Stefano notes > simple hvm containers do not perform great) I may have misunderstood this bit, WRT this last parenthetical: adding PV I/O drivers to an HVM guest is AFAIAA the single biggest improvement you can make to a bare HVM guest in terms of performance. There are indeed additional gains to be had from other PV stuff which Stefano mentions (clocks etc), but I believe those are all mostly incremental and not as impressive as the PV I/O gains (but still good improvements). That's not to say that there's an argument in the context of Linux that if you can enable PV I/O then you can also enable other PV optimisations, but I thought I would mention it. Wasn't part of the original point here to be able to enable PV I/O (and perhaps other PV stuff) for non-PAE 32-bit x86, i.e. in a context where PVMMU isn't available. (That doesn't necessarily conflict with "if you can enable PV I/O then you can also enable other PV optimisations" though) Ian.