[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.