From xen-devel-bounces@lists.xen.org Wed May 21 02:09:53 2014 Received: (at maildrop) by bugs.xenproject.org; 21 May 2014 01:09:53 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1Wmv2X-0001nQ-7x for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 21 May 2014 02:09:53 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Wmuvo-0006B8-SM; Wed, 21 May 2014 01:02:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Wmuvn-0006B1-53 for xen-devel@lists.xen.org; Wed, 21 May 2014 01:02:55 +0000 Received: from [85.158.137.68:53092] by server-7.bemta-3.messagelabs.com id 47/E5-04151-E3BFB735; Wed, 21 May 2014 01:02:54 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1400634172!5159680!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYzMTcz\n X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18436 invoked from network); 21 May 2014 01:02:53 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-3.tower-31.messagelabs.com with SMTP; 21 May 2014 01:02:53 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 20 May 2014 18:02:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,877,1392192000"; d="scan'208";a="434781676" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by azsmga001.ch.intel.com with ESMTP; 20 May 2014 18:02:44 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 20 May 2014 18:02:44 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 20 May 2014 18:02:44 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.192]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.7]) with mapi id 14.03.0123.003; Wed, 21 May 2014 09:02:41 +0800 From: "Zhang, Yang Z" To: Jan Beulich , George Dunlap Thread-Topic: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZtIw0CAgAFyMyA= Date: Wed, 21 May 2014 01:02:41 +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> <537B1E520200007800013EB7@mail.emea.novell.com> <537B4EA70200007800014085@mail.emea.novell.com> In-Reply-To: <537B4EA70200007800014085@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: "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "Keir Fraser\(keir.xen@gmail.com\)" , "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-20: >>>> On 20.05.14 at 12:12, wrote: >> On Tue, May 20, 2014 at 8:20 AM, Jan Beulich wrote: >>>>>> On 20.05.14 at 05:13, wrote: >>>> George Dunlap wrote on 2014-05-19: >>>>> Avoiding these by "hoping" that the guest OS doesn't DMA into a >>>>> video buffer isn't really robust enough. I think that was Tim >>>>> and Jan's >>>> >>>> Video buffer is only one case. How we can prevent the DMA to other >>>> reserved region? >>> >>> You continue to neglect the difference: Accessing VRAM this way is >>> legitimate (and potentially useful). And - as just said in the >>> other reply - ideally we'd also simply ignore accesses to reserved Can you give an example of what legitmate case you are mentioned twice(You mentioned it also in other reply)? I cannot understand why we need to restrict the CPU access to VRAM region but allow accessing from device. As I known, for gfx passthrough, both device and CPU are able to access them. And for emulated gfx, only software will access it which same as current we see in Xen. >>> regions (and in fact we try to, by not immediately bringing down a >>> guest device doing such). >> >> On the other hand, just to play devil's advocate here: Implementing >> separate IOMMU tables (including superpages) isn't free; it has a >> non-negligible cost, both in initial developer time, continuing >> maintenance (code complexity, fixing bugs), extra memory at >> run-time, &c. >> >> Of all the things we could invest that developer time doing, why >> should we make it possible to DMA into VRAM, rather than doing >> something else? > > While I agree that the question is valid, my position really is that > it was a mistake to implement the IOMMU code without superpage We support the superpage via sharing EPT and VT-d pagetable. > support, i.e. I view this as a shortcoming independent of the VRAM > issue, and I would want to see this fixed rather sooner than later. > Had it been done properly from the beginning (like one would expect > for non-experimental code), a lot of this discussion could have been > avoided, and we wouldn't have had to take the respective workaround > close to the 4.4 release. I still think the best solution is fixing the VRAM global log dirty mechanism which my previous patch already did. Because I cannot see any benefit with separating the page table. > > Jan Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel