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:32 AM, Boris Ostrovsky wrote:
> 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.

TBH, I don't see what needs to be done in p2m_next_level(). mfn doesn't
enter the calculation there.


-boris

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