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 07:14:32 +0100 Message-ID: <54F00B48.5010803@suse.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"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YREC2-0003k2-KH for xen-devel@lists.xenproject.org; Fri, 27 Feb 2015 06:14:34 +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" , Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Boris Ostrovsky , David Vrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 02/26/2015 07:48 PM, 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) but requires a bit of work, I'd > rather ask -- why not address *why* we are avoiding PARAVIRT / > PARAVIRT_CLOCK and stick to the original goals behind the pvops model by > addressing what is required to be able to continue to be happy with one single > kernel. The work required to do that might be more than to just be able to > build simple Xen hvm containers without PARAVIRT / PARAVIRT_CLOCK but I'd > think the gains would be much higher. I absolutely agree. I think this is a long term goal we should work on. PVH should address most of the issues, BTW. > If this resonates well then I'd like to ask: what are the current most pressing > issues with enabling PARAVIRT / PARAVIRT_CLOCK. PARAVIRT: performance, especially memory management PARAVIRT_CLOCK: none Juergen