Re: [Xen-devel] Re: Re: mapping problems in xenpaging

[Tim Deegan <tim@xxxxxxx>]

At 10:54 -0400 on 20 Oct (1319108045), Andres Lagar Cavilla wrote:
> On Thu, Oct 20, 2011 at 6:13 AM, Tim Deegan <tim@xxxxxxx> wrote:
> > At 13:59 -0400 on 13 Oct (1318514390), Andres Lagar Cavilla wrote:
> >> Good stuff Tim, let me summarize:
> >>
> >>
> >> - The key is to obtain exclusive access to a p2m entry, or range [gfn,
> >> gfn + 1<<order). This exclusive access lasts beyond the actual lookup,
> >> until the caller is finished with modifications, to prevent the p2m
> >> mapping changing underfoot.
> >
> > Yes.  It only excludes concurrent updates, not concurrent lookups, so in
> > that way it's effectively a per-range MRSW lock, implemented with
> > refcounts.  (I feel like I'm working around in a circle to your first
> > suggestion!)
> 
> That's great because ... I'm working around in a circle 180 degrees opposite 
> :)
> 
> I think it's important to untangle page liveness from mapping mutex
> access. That's why I favor Keir's approach of just locking the thing,
> no MSRW. Reasons:
> 1. Very common idiom throughout the code is to get_entry -> set_entry.
> How do we do that in an MSRW, atomically?

Callers that want to do get/set would have to acquire the write lock
during the first lookup.

> 2. You're concerned about foreign mappings, rightly so. With mutex
> access to the p2m mapping, we can ensure the page refcount increases
> atomically in the context of building the foreign mapping. This will
> keep the page alive and unable to be swapped/shared/whatever. We only
> lock the p2m entry while building the p2m mapping.

Ah - that's where we differ.  As far as I can see, in order to be
effective, the p2m entry must remain locked until the foreign mapping is
destroyed.  Otherwise, later p2m updates can make the mapping stale.

> 3. Recursive locking for different purposes is just easier without
> refcounts (generalization of reason 1)
> 4. Note that in your qemu/x86_emulate example, qemu's mapping does not
> prevent x86_emulate from progress, as qemu will have relinquished
> locks once done building the foreign mapping.
> 
> I have a draft implementation of a "tree" of exclusive locks. It's
> still a bit embarrassing to share :)
> The API is more or less
> get_p2m(p2m, gfn, order)
> <do work>
> put_p2m(p2m, gfn, order)
> with recursive get allowed, (unsophisticated) deadlock detection, and
> shortcuts for individual gfn and for global locking (for e.g.
> log_dirty). Give me a couple days for an RFC post.

Great - actual code is always welcome! :)  I might not be able to give
it much attention before next Thursday though.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel