Re: [Xen-devel] [PATCH RFC v2 3/3] xen: rework paging_log_dirty_op to work with hvm guests

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

Hello,

El 03/04/15 a les 16.12, Tim Deegan ha escrit:
> Hi,
> 
> At 20:46 +0100 on 02 Apr (1428007593), Andrew Cooper wrote:
>> On 02/04/15 11:26, Roger Pau Monne wrote:
>>> When the caller of paging_log_dirty_op is a hvm guest Xen would choke when
>>> trying to copy the dirty bitmap to the guest because the paging lock is
>>> already held.
>>
>> Are you sure? Presumably you get an mm lock ordering violation, because
>> paging_log_dirty_op() should take the target domains paging lock, rather
>> than your own (which is prohibited by the current check at the top of
>> paging_domctl()).
>>
>> Unfortunately, dropping the paging_lock() here is unsafe, as it will
>> result in corruption of the logdirty bitmap from non-domain sources such
>> as HVMOP_modified_memory.
>>
>> I will need to find some time with a large pot of coffee and a
>> whiteboard, but I suspect it might actually be safe to alter the current
>> mm_lock() enforcement to maintain independent levels for a source and
>> destination domain.
> 
> We discussed this in an earlier thread and agreed it would be better
> to try to do this work in batches rather than add more complexity to
> the mm locking rules.  (I'm AFK this week so I haven't had a chance to
> review the actual pacth yet.)

I don't know about the locking rules or how much complexity would
permitting this kind of accesses add to it, but IMHO this patch makes
the code quite more complex and possibly error prone, so finding a
simpler approach seems like a good option to me.

Roger.

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