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

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

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


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

> that's not directly displayed information, but needs to be preserved
> across migration, the only downside of this would be temporary screen
> corruption in the guest immediately following migration. Clearly far
> better than eventually turning off passed through devices due to excessive 
> IOMMU faults.
> 
>> Even worse, I think two page tables
>> introduce redundant code and maintain effort. So I wonder is it
>> really necessary to implement the separate VT-d large page?
> 
> Tim and I certainly think so. Andrew had a valid point in stating that
> guests without the need for VRAM dirty tracking, but with assigned PCI
> device(s) could still benefit from sharing page tables, so working
> towards a model where this could be retained would clearly be the optimal 
> solution.

I still cannot understand what we want to achieve or fix by separate the page 
table.

> 
> I wonder whether you actually too the time to go through the old
> thread before writing your mail, since all you did is repeat your old
> arguments, without addressing any of the reasons given why we consider
> separate page tables better than shared ones.

I have gone through it many times. But I cannot find a strong reason to 
persuade me to do it. I think it is a 'nice to have' feature, not required. 
Unless if anyone can show me that current sharing mechanism do have problem and 
it only can be fixed by separate page table, then I think we must to do it. 

> 
> Jan


Best regards,
Yang



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