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

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



>>> 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(). 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.

Jan


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

 


Rackspace

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