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

[George Dunlap <george.dunlap@eu.citrix.com>]

On 02/11/2014 12:57 PM, Jan Beulich wrote:
>>>> On 11.02.14 at 12:55, Tim Deegan <tim@xen.org> 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