[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

title 38 Implement VT-d large pages so we can avoid sharing between EPT and IOMMU
owner it Yang Z Zhang <yang.z.zhang@xxxxxxxxx>

On 02/13/2014 04:20 PM, Tim Deegan wrote:
At 15:55 +0000 on 13 Feb (1392303343), Jan Beulich wrote:
On 13.02.14 at 16:46, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
On 02/12/2014 12:53 AM, Zhang, Yang Z wrote:
George Dunlap wrote on 2014-02-11:
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.
That would be Tim then, as he would have to approve of it anyway.

I should also say that while I certainly understand the argumentation
above, I would still want to go this route only with the promise that
B is going to be worked on reasonably soon after the release, ideally
with the goal of backporting the changes for 4.4.1.

OK -- I've retitled the bug and am going to leave it open.


Xen-devel mailing list



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