From xen-devel-bounces@lists.xen.org Tue May 20 04:16:54 2014 Received: (at maildrop) by bugs.xenproject.org; 20 May 2014 03:16:54 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WmaXu-000573-5F for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 20 May 2014 04:16:54 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmaR1-0006Dx-Bo; Tue, 20 May 2014 03:09:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmaQz-0006Ds-Eq for xen-devel@lists.xen.org; Tue, 20 May 2014 03:09:45 +0000 Received: from [85.158.143.35:20417] by server-1.bemta-4.messagelabs.com id D1/52-09853-877CA735; Tue, 20 May 2014 03:09:44 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1400555383!2518702!1 X-Originating-IP: [192.55.52.93] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17820 invoked from network); 20 May 2014 03:09:44 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by server-16.tower-21.messagelabs.com with SMTP; 20 May 2014 03:09:44 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 19 May 2014 20:09:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,870,1392192000"; d="scan'208";a="541822182" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by fmsmga002.fm.intel.com with ESMTP; 19 May 2014 20:09:14 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 May 2014 20:09:13 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 May 2014 20:09:13 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.192]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.7]) with mapi id 14.03.0123.003; Tue, 20 May 2014 11:09:10 +0800 From: "Zhang, Yang Z" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZquITGwgAIV/CWAAJImEIACCY0AgAACsICAAAbjAICVQRIQ//+SX4CAAaiQIA== Date: Tue, 20 May 2014 03:09:10 +0000 Message-ID: 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> <5379E50702000078000136F6@mail.emea.novell.com> In-Reply-To: <5379E50702000078000136F6@mail.emea.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: Keir Fraser , George Dunlap , "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "Nakajima, Jun" , "Zhang, Xiantao" 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 Jan Beulich wrote on 2014-05-19: >>>> 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. Yes, but I am not buying in it since I think it not the right direction to fix this issue: This is my original point: Actually, the first solution came to my mind is B. Then I realized that even chose B, we still cannot track the memory updating from DMA(even with A/D bit, it still a problem). Also, considering the current usage case of log dirty in Xen(only vram tracking has problem), I though A is better.: Hypervisor only need to track the vram change. If a malicious guest try to DMA to vram range, it only crashed himself (This should be reasonable). > >> 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 It is easy to trigger an IOMMU faults by guest, like set an invalid DMA address. We cannot prevent it. > 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 still cannot understand what we want to achieve or fix by separate the page table. > > 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. I have gone through it many times. But I cannot find a strong reason to persuade me to do it. I think it is a 'nice to have' feature, not required. Unless if anyone can show me that current sharing mechanism do have problem and it only can be fixed by separate page table, then I think we must to do it. > > Jan Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel