[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

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


Xen-devel mailing list



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