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

[Tim Deegan <tim@xxxxxxx>]

At 12:09 +0200 on 07 Apr (1428408556), Roger Pau Monné wrote:
> 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.

I'm happier with this (relatively contained) complexity than with
adding yet more logic to the mm_locks code.

I don't think there are any new races introduced here that weren't
already present in the -ERESTART case.

Cheers,

Tim.

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