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

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

George Dunlap wrote on 2014-05-19:
>> 
>> Hi all
>> 
>> Sorry to turn out this old thread.
>> 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

You cannot prevent guest to trigger the IOMMU faults. It is easy to trigger an 
IOMMU fault by setting a invalid DMA address.

> 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

Video buffer is only one case. How we can prevent the DMA to other reserved 
region?

> primary reason for wanting the ability to have separate tables for HAP and 
> IOMMU.
> 
> Is that about right, Jan / Tim?
> 
>  -George


Best regards,
Yang


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