From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Wroblewski Subject: Re: GPU passthrough performance regression in >4GB vms due to XSA-60 changes Date: Mon, 19 May 2014 17:48:02 +0200 Message-ID: <537A27B2.5010404@gmail.com> References: <537484A9.9000001@gmail.com> <5374CFF80200007800012A53@mail.emea.novell.com> <5374AEBD.7090403@gmail.com> <5374DBFD0200007800012AEE@mail.emea.novell.com> <5374C389.507@gmail.com> <5374D08F.2050202@gmail.com> <5374D5B0.2080808@gmail.com> <537502710200007800012C7E@mail.emea.novell.com> <5374DFCA.10207@gmail.com> <5375CD4F0200007800012E27@mail.emea.novell.com> <5375F410.2060406@gmail.com> <537614F30200007800013139@mail.emea.novell.com> <53763E9B0200007800013260@mail.emea.novell.com> <5379DD1A.6050106@gmail.com> <5379FB2902000078000137EC@mail.emea.novell.com> <5379E149.1020504@gmail.com> <537A020B0200007800013865@mail.emea.novell.com> <5379EBC1.5050902@gmail.com> <537A0FF10200007800013973@mail.emea.novell.com> <5379F65A.7020609@gmail.com> <537A18B90200007800013A09@mail.emea.novell.com> <537A131C.8010303@gmail.com> <537A3E650200007800013C04@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" 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 1WmPnL-0006yS-CQ for xen-devel@lists.xenproject.org; Mon, 19 May 2014 15:48:07 +0000 Received: by mail-we0-f176.google.com with SMTP id q59so5584150wes.7 for ; Mon, 19 May 2014 08:48:05 -0700 (PDT) In-Reply-To: <537A3E650200007800013C04@mail.emea.novell.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: Jan Beulich , Tim Deegan Cc: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 05/19/2014 05:24 PM, Jan Beulich wrote: >>>> On 19.05.14 at 16:20, wrote: >> On 05/19/2014 02:44 PM, Jan Beulich wrote: >>> I used plural for a reason - I'm afraid you would need to start out with >>> taking them all, and then possibly determine which ones to drop as >>> being unrelated to the issue at hand. >> Looks like a partial backport of your commit >> >> commit aa9114edd97b292cd89b3616e3f2089471fd2201 >> Author: Jan Beulich >> Date: Thu Apr 10 16:01:41 2014 +0200 >> >> x86/EPT: force re-evaluation of memory type as necessary >> >> is all that's necessary. Attaching it versus 4.3.2. I only left the >> memory_type_change calls in MTRR related areas, since only this is >> problematic for the particular issue. This is probably good enough for >> us, thanks for the pointers! Do you think this one is a relatively safe >> for the stable branches? > I'm rather reluctant to put in any half-baked stuff like this - in going > through the set of changes you certainly noticed that there are > quite a few more fixes, that all deal with similar problems. So the > partial (and amended) backport you provided is really of the sort > "my problem is fixed, let's ignore everything else"... Yup. Backporting the smallest viable fix seems ok solution for us, so I did it and we'll test it a bit, but I fully agree it's likely not the best thing for upstream project especially since that code seems very fresh. Given there doesn't seem to be much noise about recent (and very obvious) vm performance regressions with pci passthrough and large amounts of memory, it might be quite an unpopular use case to justify the risky backport. > Independently of this - Tim, do you think this EPT misconfig stuff can > already be considered mature enough for backporting? It's been in a > little over a month, and considering that we're using formally > undefined behavior here, I'd rather view this as not yet a backport > candidate. > > Jan >