[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); 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. > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |