From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: RFC: xen config changes v4 Date: Fri, 27 Feb 2015 10:55:57 +0100 Message-ID: <54F03F2D.8050209@suse.com> References: <20150226015305.GE8749@wotan.suse.de> <54EEA847.6070505@suse.com> <54EEF0A7.6060804@citrix.com> <20150226172925.GL8749@wotan.suse.de> <54F00A36.1060608@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YRHeL-0004xG-4n for xen-devel@lists.xenproject.org; Fri, 27 Feb 2015 09:56:01 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: "Luis R. Rodriguez" , David Vrabel , Jan Beulich , xen-devel@lists.xenproject.org, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On 02/27/2015 10:41 AM, Stefano Stabellini wrote: > On Fri, 27 Feb 2015, Juergen Gross wrote: >> On 02/26/2015 06:42 PM, 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. >> >> Hmm, after checking the code I'm not convinced: >> >> - HVMOP_pagetable_dying is obsolete on modern hardware supporting >> EPT/HAP > > That might be true, but what about older hardware? > Even on modern hardware a few workloads still run faster on shadow. > But if HVMOP_pagetable_dying is the only reason to keep PARAVIRT for HVM > guests, then I agree with you that we should remove it. > > >> - PV IPIs are not needed on single-vcpu guests >> >> - PARAVIRT_CLOCK doesn't need PARAVIRT (in fact the SUSEs kernel configs >> for all x86_64 kernels have CONFIG_PARAVIRT_CLOCK=y) >> >> So I think we really should enable building Xen frontends without >> PARAVIRT, implying at least no XEN_PV and no XEN_PVH. >> >> I'll have a try setting up patches. > > If we are doing this as a performance improvement, I would like to see a > couple of benchmarks (kernbench, hackbench) to show that on a > single-vcpu guest and multi-vcpu guest (let's say 4 vcpus) disabling > PARAVIRT leads to better performance on Xen on EPT hardware. This is not meant to be a performance improvement. It is meant to enable a standard distro kernel configured without PARAVIRT to be able to run as a HVM guest using the pv-drivers. Juergen