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 15:27, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Mon, May 19, 2014 at 8:48 AM, Zhang, Yang Z <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. 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. 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?
> 
> Yes, it does introduce redundant code.  But unfortunately, IOMMU
> faults at the moment have to be considered rather risky; having on
> happens risks (in order of decreasing probability / increasing
> damage):
> * Device stops working for that VM until an FLR (losing a lot of its state)
> * The VM has to be killed
> * The device stops working until a host reboot
> * The host crashes
> 
> Avoiding these by "hoping" that the guest OS doesn't DMA into a video
> buffer isn't really robust enough.  I think that was Tim and Jan's
> primary reason for wanting the ability to have separate tables for HAP
> and IOMMU.
> 
> Is that about right, Jan / Tim?

Yes, and not just "about" (perhaps with the exception that I think/
hope we don't have any lurking host crashes here).

Jan


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