From xen-devel-bounces@lists.xen.org Tue Feb 11 13:03:17 2014 Received: (at maildrop) by bugs.xenproject.org; 11 Feb 2014 13:03:17 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WDCzd-0004WM-4n for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 11 Feb 2014 13:03:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDCuW-0003rt-E5; Tue, 11 Feb 2014 12:58:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDCuV-0003ro-5a for xen-devel@lists.xen.org; Tue, 11 Feb 2014 12:57:59 +0000 Received: from [85.158.143.35:21087] by server-1.bemta-4.messagelabs.com id 07/0A-31661-65E1AF25; Tue, 11 Feb 2014 12:57:58 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1392123477!4821761!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ4MDU=\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13983 invoked from network); 11 Feb 2014 12:57:58 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Feb 2014 12:57:58 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 11 Feb 2014 12:57:52 +0000 Message-Id: <52FA2C63020000780011B201@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Tue, 11 Feb 2014 12:57:55 +0000 From: "Jan Beulich" To: "Tim Deegan" References: <1392012840-22555-1-git-send-email-yang.z.zhang@intel.com> <20140210080314.GA758@deinos.phlegethon.org> <20140211090202.GC92054@deinos.phlegethon.org> <20140211115553.GB97288@deinos.phlegethon.org> In-Reply-To: <20140211115553.GB97288@deinos.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline Cc: George Dunlap , "andrew.cooper3@citrix.com" , Yang Z Zhang , Xiantao Zhang , "xen-devel@lists.xen.org" 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 11.02.14 at 12:55, Tim Deegan wrote: > At 10:59 +0000 on 11 Feb (1392112778), George Dunlap wrote: >> What I'm missing here is what you think a proper solution is. > > A _proper_ solution would be for the IOMMU h/w to allow restartable > faults, so that we can do all the usual fault-driven virtual memory > operations with DMA. :) In the meantime... Or maintaining the A/D bits for IOMMU side accesses too. >> It seems we have: >> >> A. Share EPT/IOMMU tables, only do log-dirty tracking on the buffer >> being tracked, and hope the guest doesn't DMA into video ram; DMA >> causes IOMMU fault. (This really shouldn't crash the host under normal >> circumstances; if it does it's a hardware bug.) > > Note "hope" and "shouldn't" there. :) > >> B. Never share EPT/IOMMU tables, and hope the guest doesn't DMA into >> video ram. DMA causes missed update to dirty bitmap, which will >> hopefully just cause screen corruption. > > Yep. At a cost of about 0.2% in space and some extra bookkeeping > (for VMs that actually have devices passed through to them). > The extra bookkeeping could be expensive in some cases, but basically > all of those cases are already incompatible with IOMMU. > >> C. Do buffer scanning rather than dirty vram tracking (SLOW) >> D. Don't allow both a virtual video card and pass-through > > E. Share EPT and IOMMU tables until someone turns on log-dirty mode > and then split them out. That one Wouldn't that be problematic in terms of memory being available, namely when using ballooning in Dom0? >> Given that most operating systems will probably *not* DMA into video >> ram, and that an IOMMU fault isn't *supposed* to be able to crash the >> host, 'A' seems like the most reasonable option to me. > > Meh, OK. I prefer 'B' but 'A' is better than nothing, I guess, and > seems to have most support from other people. On that basis this > patch can have my Ack. I too would consider B better than A. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel