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

[Tim Deegan <tim@xxxxxxx>]

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. 

> I think the point is that we cannot track the
> memory updating via DMA. So the user should use the log dirty mode
> carefully. Also, I am not sure whether the memory updating from dom0
> and QEMU is tracked currently.

Yes, dom0 and qemu updates are tracked in the log-dirty bitmaps.

Tim.

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