From xen-devel-bounces@lists.xen.org Tue May 20 11:53:37 2014 Received: (at maildrop) by bugs.xenproject.org; 20 May 2014 10:53:37 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1Wmhft-0001Lr-H2 for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 20 May 2014 11:53:37 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmhZ7-0002BZ-N9; Tue, 20 May 2014 10:46:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmhZ5-0002BU-CR for xen-devel@lists.xen.org; Tue, 20 May 2014 10:46:35 +0000 Received: from [85.158.139.211:8702] by server-3.bemta-5.messagelabs.com id D2/9E-28132-A823B735; Tue, 20 May 2014 10:46:34 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1400582793!5295024!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 1835 invoked from network); 20 May 2014 10:46:33 -0000 Received: from mail.emea.novell.com (HELO mail.emea.novell.com) (130.57.118.101) by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 May 2014 10:46:33 -0000 Received: from EMEA1-MTA by mail.emea.novell.com with Novell_GroupWise; Tue, 20 May 2014 11:46:33 +0100 Message-Id: <537B4EA70200007800014085@mail.emea.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.0 Date: Tue, 20 May 2014 11:46:31 +0100 From: "Jan Beulich" To: "George Dunlap" 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> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "Keir Fraser\(keir.xen@gmail.com\)" , Jun Nakajima , Yang Z Zhang , 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 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 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 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel