Re: dom0 pvops crash

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 01/25/2010 11:31 AM, Keir Fraser wrote:
> On 25/01/2010 19:00, "Jeremy Fitzhardinge"<jeremy@goop.org>  wrote:
>
>    
>> On 01/25/2010 10:57 AM, Keir Fraser wrote:
>>      
>>> Perhaps we need a branch in the git repo that includes just-get-it-working
>>> patches? Aren't we going to have a 4.0 stable branch anyway, which would do
>>> the trick?
>>>
>>>        
>> Yeah.  I don't think there's an upstreamable fix, but we can hack
>> something together to make it work.
>>      
> Hm, do you mean 'we don't currently have an upstreamable fix', or 'there is
> no possible upstreamable fix now or ever'?
>    

I'll need to refresh my memory for the precise details, but the basic 
problem is that there's a path in the pagefault code where the kernel 
breaks its own locking rules by kmapping a high pte page without holding 
the pagetable lock.  In the native case this is OK, but it breaks Xen 
because the pte page can be unpinned at that point, but can race with it 
being pinned on another CPU.This can fail in several ways, depending on 
the exact timing: the other CPU's pin could fail because of the writable 
kmapping, or the writable kmap could fail because the page has since 
become pinned.

The brute-force fix is to lock the pte page properly, but given that its 
in the hot part of the pagefault path, and the unlocked access is 
presumably a performance enhancement, I don't think that will fly.

IanC, Pasi, myself and others explored a number of other ways to try and 
fix it in the Xen pvops code, but they all turned out to be very 
expensive, just not work (they just pushed the race around), or require 
new pvops just for this case.  Given that HIGHPTE is generally a bad 
idea and should be deprecated (any machine big enough to need it should 
definitely be running a 64-bit kernel), I've left it on the backburner 
hoping for some inspiration to strike.  So far it has not.

     J