[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] get_gfn_query() locking

>>> On 30.10.12 at 15:53, Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx> wrote:
> On Oct 30, 2012, at 5:36 AM, Tim Deegan <tim@xxxxxxx> wrote:
> I say this because a similar interlock may apply for vMCE? Is there an 
> expectation for a domain with vMCE turned on to be "land-locked" memory-wise?

I don't think there's any dependency here, vMCE should be
transparent in that respect.

>>> And then again, with the p2m lock being recursive these
>>> days, I don't think there's any harm calling the other methods
>>> here with that lock held.
> Is the patch you refer to 
> http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in 
> question the following?
> + get_gfn_query(d, pfn, &pt); 
> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
> + put_gfn(d, pfn); 


> There really is no way to get rid of that p2m lock-protected critical section 
> if the domain allows for paging etc.

I wasn't questioning the locking here. It was merely that code (and
the lack of error handling therein) that made me look at the definition
of the used p2m constructs.

> You might want to introduce a 
> syntactically cleaner unconditional p2m_change_type variant that doesn't 
> cmpxchg with the previous type -- that is effectively what goes on here. 
> Should 
> be a tiny amount of refactoring and the code will be cleaner, no need for 
> query or put.

That might help here, yes.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.