Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.02.14 at 12:55, Tim Deegan <tim@xxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel