Re: [Xen-devel] [PATCH RFC 1/2] xen/pvh: take the p2m lock when doing logdirty ops from HVM domains

[Tim Deegan <tim@xxxxxxx>]

At 15:15 +0100 on 16 Oct (1413468955), Jan Beulich wrote:
> > Ah, I see.  This is the _caller_'s p2m lock but the _target_'s paging
> > lock.  Holding the caller's p2m lock to unstick this seems a bit of a
> > strange answer -- the paging op might be quite a long one.  And having
> > all vcpus take their own p2m locks before remote paging locks (and
> > probably other MM locks too operations) is going to be quite messy.
> 
> But isn't the lock order enforcement meant to do its job only within
> a single domain? I.e. isn't it a bug when it chokes on one domain's
> P2M lock getting acquired while another domain's paging lock is
> already being held?

That was my first thought, but in fact there are still deadlocks to
watch out for if we allow the ordering to be different for foreign
locks, e.g.:
- CPU 0 holds domA's paging lock, spins on domB's p2m lock.
- CPU 1 holds domB's paging lock, spins on domA's p2m lock.
- CPU 2 holds domA's p2m lock, spins on domA's paging lock.
- CPU 3 holds domB's p2m lock, spins on domB's paging lock.

The current simple rules avoid having to think about that stuff at
all, which I like.

Most hypercalls will finish their work and drop locks before they
write reults back to the caller; unfortunately things like lgd bitmaps
have potentially very large amounts of writing to do.

If it's just this operation, and maybe one or two more, maybe we can
reshuffle them to avoid doing the writeback with other locks held.

Tim.

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