From xen-devel-bounces@lists.xen.org Tue Feb 11 16:01:23 2014 Received: (at maildrop) by bugs.xenproject.org; 11 Feb 2014 16:01:23 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WDFly-0006QM-Vo for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 11 Feb 2014 16:01:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDFh3-0003FR-C7; Tue, 11 Feb 2014 15:56:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDFh2-0003F5-At for xen-devel@lists.xen.org; Tue, 11 Feb 2014 15:56:16 +0000 Received: from [85.158.137.68:7904] by server-7.bemta-3.messagelabs.com id 65/FF-13775-F184AF25; Tue, 11 Feb 2014 15:56:15 +0000 X-Env-Sender: George.Dunlap@citrix.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1392134172!1146665!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19032 invoked from network); 11 Feb 2014 15:56:14 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 11 Feb 2014 15:56:14 -0000 X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208";a="101638426" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 11 Feb 2014 15:55:59 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Tue, 11 Feb 2014 10:55:59 -0500 Received: from gateway-cbg.eng.citrite.net ([10.80.16.17] helo=[0.0.0.0]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1WDFgl-0005NT-2P; Tue, 11 Feb 2014 15:55:59 +0000 Message-ID: <52FA480D.9040707@eu.citrix.com> Date: Tue, 11 Feb 2014 15:55:57 +0000 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jan Beulich , 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> <52FA2C63020000780011B201@nat28.tlf.novell.com> In-Reply-To: <52FA2C63020000780011B201@nat28.tlf.novell.com> X-DLP: MIA1 Cc: Yang Z Zhang , "andrew.cooper3@citrix.com" , 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/11/2014 12:57 PM, Jan Beulich wrote: >>>> 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. I think I got a bit distracted with the "A isn't really so bad" thing. Actually, if the overhead of not sharing tables isn't very high, then B isn't such a bad option. In fact, B is what I expected Yang to submit when he originally described the problem. I was going to say, from a release perspective, B is probably the safest option for now. But on the other hand, if we've been testing sharing all this time, maybe switching back over to non-sharing whole-hog has the higher risk? Anyway, both are at least probably equal risk-wise. How easy is it to implement? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel