[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 05/19/2014 02:50 PM, Jan Beulich wrote:
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
* 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).

I think the fear was that buggy hardware might cause a host crash / hang.


Xen-devel mailing list



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