[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



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 think it would be better not to allow VT-d and EPT to share
> pagetables in cases where devices are passed through (i.e. all cases where 
> VT-d is in use).

Without VT-d and EPT share page, we still cannot track the memory updating from 
DMA. 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.

> 
> Tim.


Best regards,
Yang



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


 


Rackspace

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