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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.05.14 at 05:09, <yang.z.zhang@xxxxxxxxx> wrote:
> Jan Beulich wrote on 2014-05-19:
>>>>> On 19.05.14 at 09:48, <yang.z.zhang@xxxxxxxxx> wrote:
>>> Because I just noticed that someone is asking when Intel will
>>> implement the VT-d page table separately. Actually, I am totally unaware it.
>> 
>> This was a request sent directly to you, so it shouldn't be a surprise.
> 
> Yes, but I am not buying in it since I think it not the right direction to 
> fix this issue:
> 
> This is my original point:
> 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).

Except that the guest in no way needs to be malicious. I think you
forget that the ultimate goal of virtualization ought to be to make
guests behave the same (in terms of correctness, not generally in
terms of performance) as if run on real hardware, not matter what
they do. And DMA to VRAM wouldn't crash on real hardware (and I
can see legitimate uses of such).

>>> The original
>>> issue that this patch tries to fix is the VRAM tracking which using
>>> the global log dirty mode. And I thought the best solution to fix it
>>> is in VRAM side not VT-d side. Because even use separate VT-d page
>>> table, we still cannot track the memory update from DMA.
>> 
>> Correct. But at least we can avoid IOMMU faults by not marking read-
>> only the VRAM region. Unless the guest stores data in the VRAM region
> 
> It is easy to trigger an IOMMU faults by guest, like set an invalid DMA 
> address. We cannot prevent it.

Correct (and this btw also contradicts above spelled out goal: On
real hardware this would in the majority of cases also just cause
certain operations to become ineffectual rather than bring down
the system - we just have to be more rigid here to deal with
potential malicious guests).

Jan


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