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

[Tim Deegan <tim@xxxxxxx>]

At 10:59 +0000 on 11 Feb (1392112778), George Dunlap wrote:
> On Tue, Feb 11, 2014 at 9:02 AM, Tim Deegan <tim@xxxxxxx> wrote:
> > At 08:15 +0000 on 10 Feb (1392016516), Zhang, Yang Z wrote:
> >> Tim Deegan wrote on 2014-02-10:
> >> > At 14:14 +0800 on 10 Feb (1392038040), Yang Zhang wrote:
> >> >> From: Yang Zhang <yang.z.zhang@xxxxxxxxx>
> >> >>
> >> >> When enabling log dirty mode, it sets all guest's memory to readonly.
> >> >> And in HAP enabled domain, it modifies all EPT entries to clear
> >> >> write bit to make sure it is readonly. This will cause problem if
> >> >> VT-d shares page table with EPT: the device may issue a DMA write
> >> >> request, then VT-d engine tells it the target memory is readonly and
> >> >> result in VT-d
> >> > fault.
> >> >
> >> > So that's a problem even if only the VGA framebuffer is being tracked
> >> > -- DMA from a passthrough device will either cause a spurious error or
> >> > fail to update the dirt bitmap.
> >>
> >> Do you mean the VGA frambuffer will be used as DMA buffer in guest? If 
> >> yes, I think it's guest's responsibility to ensure it never happens.
> >>
> >
> > I don't think that works.  We can't expect arbitrary OSes to (a) know
> > they're running on Xen and (b) know that that means they can't DMA to
> > or from their framebuffers.
> >
> >> Without VT-d and EPT share page, we still cannot track the memory
> >> updating from DMA.
> >
> > Yeah, but at least we don't risk crashing the _host_ by throwing DMA
> > failures around.
> 
> What I'm missing here is what you think a proper solution is.

A _proper_ solution would be for the IOMMU h/w to allow restartable
faults, so that we can do all the usual fault-driven virtual memory
operations with DMA. :)  In the meantime...

>  It seems we have:
> 
> A. Share EPT/IOMMU tables, only do log-dirty tracking on the buffer
> being tracked, and hope the guest doesn't DMA into video ram; DMA
> causes IOMMU fault. (This really shouldn't crash the host under normal
> circumstances; if it does it's a hardware bug.)

Note "hope" and "shouldn't" there. :)

> B. Never share EPT/IOMMU tables, and hope the guest doesn't DMA into
> video ram.  DMA causes missed update to dirty bitmap, which will
> hopefully just cause screen corruption.

Yep.  At a cost of about 0.2% in space and some extra bookkeeping
(for VMs that actually have devices passed through to them).
The extra bookkeeping could be expensive in some cases, but basically
all of those cases are already incompatible with IOMMU.

> C. Do buffer scanning rather than dirty vram tracking (SLOW)
> D. Don't allow both a virtual video card and pass-through

E. Share EPT and IOMMU tables until someone turns on log-dirty mode
and then split them out.  That one 

> Given that most operating systems will probably *not* DMA into video
> ram, and that an IOMMU fault isn't *supposed* to be able to crash the
> host, 'A' seems like the most reasonable option to me.

Meh, OK.  I prefer 'B' but 'A' is better than nothing, I guess, and
seems to have most support from other people.  On that basis this
patch can have my Ack.

Is it intended for 4.4 as a bugfix (i.e. should I be checking it in?)

Tim.

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