[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 

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

Best regards,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.