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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

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 <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.
> 
> 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.

> 
> Anyway, both are at least probably equal risk-wise.  How easy is it to
> implement?
> 
>   -George


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel