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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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
> > 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).
I think the fear was that buggy hardware might cause a host crash / hang.

 -George

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