Re: [Xen-devel] [PATCH v2 for-4.9] x86/mm: Fix incorrect unmapping of 2MB and 1GB pages

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 05/23/2017 10:05 AM, Jan Beulich wrote:
>>>> On 23.05.17 at 15:40, <boris.ostrovsky@xxxxxxxxxx> wrote:
>> And you haven't been able to reproduce this? I see this fail on two AMD
>> systems (different processor families).
> I didn't even have the time to try.
>
>> And this:
>>
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -560,7 +560,7 @@ int p2m_set_entry(struct p2m_domain *p2m, unsigned long 
>> gfn, mfn_t mfn,
>>      {
>>          if ( hap_enabled(d) )
>>          {
>> -            unsigned long fn_mask = !mfn_eq(mfn, INVALID_MFN) ?
>> +            unsigned long fn_mask = (!mfn_eq(mfn, INVALID_MFN) || 1)?
>>                                       (gfn | mfn_x(mfn) | todo) : (gfn | 
>> todo);
>>  
>>              order = (!(fn_mask & ((1ul << PAGE_ORDER_1G) - 1)) &&
>>
>>
>> makes the problem go away.
> Interesting. I took another look at p2m-pt.c, this time paying
> particular attention to INVALID_MFN uses. And right the first one
> may already provide a hint: Perhaps we now need L2 and L3
> counterparts to p2m_l1e_from_pfn(). 

Defining p2m_l2e_from_pfn indeed helps a bit with HVM --- the guest now
goes as far as loading balloon driver (when it crashes).


> Further changes may then
> be needed to the splitting of large pages (in p2m_next_level())
> depending on whether INVALID_MFN entries can make it there.

Let me see what I can do here.

-boris


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