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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

Jan


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