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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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

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.

 -George

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