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

Re: [Xen-devel] [PATCH 3 of 6] x86/mm/shadow: fix potential p2m/paging deadlock when emulating page table writes



On Apr 19, 2012, at 10:51 AM, Tim Deegan wrote:

> At 09:25 -0700 on 18 Apr (1334741158), Andres Lagar-Cavilla wrote:
>>> Nack, at least for now; we spent a fair amount of effort taking all this
>>> emulation code out from under the shadow lock; serializing it under the
>>> p2m lock would be unfortunate.  The other patches are less worrying,
>>> since they wrap a shadow_lock() in a p2m_lock() but I hope they can all
>>> be avoided.
>>> 
>>> The existing interlock between the shadow code and the p2m code prevents
>>> any p2m modifications from happening when the shadow lock is held, so I
>>> hope I can solve this by switching to unlocked lookups instead.  I'm
>>> building a test kernel now to tell me exactly which lookps are to
>>> blame.
>> 
>> FWIW, get_gfn_query for the target gfn of the PTE entry that is being
>> checked in validate_gl?e entry, is the call that causes the panic this
>> patch tries to fix.
>> 
>> As for the other two patches, sh_resync_l1 is the trigger (again,
>> get_gfn_query on the gfn that is contained by the PTE being verified)
> 
> Thanks.  I've taken a sweep through mm/shadow, making the lookups into
> unlocked ones wherever the paging_lock is already held.  With the
> attached patch and your final patch to enable the locking, I can start
> HVM guests without crashing Xen.  I haven't given it any more serious
> testing yet.

It looks good to me. Thanks. 
Acked-by Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>

Andres
> 
> Cheers,
> 
> Tim.<shadow-vs-p2m.txt>


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


 


Rackspace

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