Re: [Xen-devel] get_gfn_query() locking

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

On Oct 30, 2012, at 11:09 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:

>>>> 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); 
> 
> Yes.
> 
>> 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.

Remind if I don't get around to adding this to a cleanup

Andres

> 
>> 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.
> 
> Jan
> 


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