[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |