From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] Don't track all memory when enabling log dirty to track vram Date: Tue, 11 Feb 2014 15:55:57 +0000 Message-ID: <52FA480D.9040707@eu.citrix.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52FA2C63020000780011B201@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Tim Deegan Cc: Yang Z Zhang , "andrew.cooper3@citrix.com" , Xiantao Zhang , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.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