From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Re: Re: mapping problems in xenpaging Date: Thu, 20 Oct 2011 16:31:55 +0100 Message-ID: <20111020153155.GL49983@ocelot.phlegethon.org> References: <20111010092111.GB31800@ocelot.phlegethon.org> <20111013150229.GJ44937@ocelot.phlegethon.org> <20111020101324.GD49983@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andres Lagar Cavilla Cc: zhen shi , Olaf Hering , Keir Fraser , xen-devel@lists.xensource.com, Adin Scannell List-Id: xen-devel@lists.xenproject.org At 10:54 -0400 on 20 Oct (1319108045), Andres Lagar Cavilla wrote: > On Thu, Oct 20, 2011 at 6:13 AM, Tim Deegan 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< >> 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) > > 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.