|
[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 |