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: Thu, 13 Feb 2014 15:46:06 +0000 Message-ID: <52FCE8BE.8050105@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> <52FA480D.9040707@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Zhang, Yang Z" , Jan Beulich , Tim Deegan Cc: "andrew.cooper3@citrix.com" , "Zhang, Xiantao" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 02/12/2014 12:53 AM, Zhang, Yang Z wrote: > George Dunlap wrote on 2014-02-11: >> 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. > Actually, the first solution came to my mind is B. Then I realized that even chose B, we still cannot track the memory updating from DMA(even with A/D bit, it still a problem). Also, considering the current usage case of log dirty in Xen(only vram tracking has problem), I though A is better.: Hypervisor only need to track the vram change. If a malicious guest try to DMA to vram range, it only crashed himself (This should be reasonable). > >> 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? > Another problem with B is that current VT-d large paging supporting relies on the sharing EPT and VT-d page table. This means if we choose B, then we need to re-enable VT-d large page. This would be a huge performance impaction for Xen 4.4 on using VT-d solution. OK -- if that's the case, then it definitely tips the balance back to A. Unless Tim or Jan disagrees, can one of you two check it in? Don't rush your judgement; but it would be nice to have this in before RC4, which would mean checking it in today preferrably, or early tomorrow at the latest. -George