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

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

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

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@eu.citrix.com> 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.
> Done.
>
>> 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.
> Agreed.

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

  -George