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

[Tim Deegan <tim@xxxxxxx>]

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.)

> Up until now, the toolstack domain has always been PV (with very little
> in the way of locking), and I don't believe our current locking model is
> suitable for an HVM domain performing toolstack operations on another,
> where both the source and destination need locking.

AFAICT this is the only place in the hypervisor where a hypercall
copies data back with target domain's paging locks held.

Tim.

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