WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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