From xen-devel-bounces@lists.xen.org Mon May 19 10:10:23 2014 Received: (at maildrop) by bugs.xenproject.org; 19 May 2014 09:10:24 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WmJaR-0002CE-UY for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 19 May 2014 10:10:23 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmJTy-0006uu-Ak; Mon, 19 May 2014 09:03:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmJTx-0006un-4w for xen-devel@lists.xen.org; Mon, 19 May 2014 09:03:41 +0000 Received: from [85.158.137.68:42629] by server-9.bemta-3.messagelabs.com id 07/EA-30063-CE8C9735; Mon, 19 May 2014 09:03:40 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1400490219!2235601!1 X-Originating-IP: [130.57.118.101] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25210 invoked from network); 19 May 2014 09:03:39 -0000 Received: from mail.emea.novell.com (HELO mail.emea.novell.com) (130.57.118.101) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 May 2014 09:03:39 -0000 Received: from EMEA1-MTA by mail.emea.novell.com with Novell_GroupWise; Mon, 19 May 2014 10:03:39 +0100 Message-Id: <5379E50702000078000136F6@mail.emea.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.0 Date: Mon, 19 May 2014 10:03:35 +0100 From: "Jan Beulich" To: "Yang Z Zhang" References: <20140210080314.GA758@deinos.phlegethon.org> <20140211090202.GC92054@deinos.phlegethon.org> <20140211115553.GB97288@deinos.phlegethon.org> <52FA2C63020000780011B201@nat28.tlf.novell.com> <52FA480D.9040707@eu.citrix.com> <52FCE8BE.8050105@eu.citrix.com> <52FCF90F020000780011C29A@nat28.tlf.novell.com> <20140213162022.GE82703@deinos.phlegethon.org> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Keir Fraser , George Dunlap , "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , Jun Nakajima , Xiantao Zhang Subject: Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 19.05.14 at 09:48, wrote: > Because I just noticed that someone is asking when Intel will implement the > VT-d page table separately. Actually, I am totally unaware it. This was a request sent directly to you, so it shouldn't be a surprise. > The original > issue that this patch tries to fix is the VRAM tracking which using the > global log dirty mode. And I thought the best solution to fix it is in VRAM > side not VT-d side. Because even use separate VT-d page table, we still cannot > track the memory update from DMA. Correct. But at least we can avoid IOMMU faults by not marking read- only the VRAM region. Unless the guest stores data in the VRAM region that's not directly displayed information, but needs to be preserved across migration, the only downside of this would be temporary screen corruption in the guest immediately following migration. Clearly far better than eventually turning off passed through devices due to excessive IOMMU faults. > Even worse, I think two page tables > introduce redundant code and maintain effort. So I wonder is it really > necessary to implement the separate VT-d large page? Tim and I certainly think so. Andrew had a valid point in stating that guests without the need for VRAM dirty tracking, but with assigned PCI device(s) could still benefit from sharing page tables, so working towards a model where this could be retained would clearly be the optimal solution. I wonder whether you actually too the time to go through the old thread before writing your mail, since all you did is repeat your old arguments, without addressing any of the reasons given why we consider separate page tables better than shared ones. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel