|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/3] x86: nuke PV superpage option and code
On 24/07/17 15:02, Wei Liu wrote:
> @@ -1317,8 +1285,13 @@ static int put_page_from_l2e(l2_pgentry_t l2e,
> unsigned long pfn)
> return 1;
>
> if ( l2e_get_flags(l2e) & _PAGE_PSE )
> - put_superpage(l2e_get_pfn(l2e));
> - else
> + {
> + struct page_info *page = mfn_to_page(l2e_get_pfn(l2e));
> + unsigned int i;
> +
> + for ( i = 0; i < (1u << PAGETABLE_ORDER); i++, page++ )
> + put_page_and_type(page);
With the removal of PV superpages, can this _PAGE_PSE check ever be hit?
> + } else
> put_page_and_type(l2e_get_page(l2e));
>
> return 0;
> diff --git a/xen/include/asm-x86/guest_pt.h b/xen/include/asm-x86/guest_pt.h
> index 72126d58d5..af18c90efa 100644
> --- a/xen/include/asm-x86/guest_pt.h
> +++ b/xen/include/asm-x86/guest_pt.h
> @@ -210,7 +210,7 @@ static inline bool guest_can_use_l2_superpages(const
> struct vcpu *v)
> * It's also used in the dummy PT for vcpus with CR0.PG cleared.
> */
> return (is_pv_vcpu(v)
> - ? opt_allow_superpage
> + ? false
This raises an interesting question. A PV guest likely has 2M
superpages in the M2P mapping, irrespective of whether the PV guest is
permitted to create its own 2M superpages or not.
In this context, I think it is a layering violation. The purpose of
guest_walk() is to match what hardware does, whereas this check is
superimposing PV policy.
I will submit a patch changing this in isolation, along with suitable
justification.
> diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
> index 44e86d6a1f..6dcf5e9ca8 100644
> --- a/xen/include/asm-x86/paging.h
> +++ b/xen/include/asm-x86/paging.h
> @@ -372,7 +372,7 @@ static inline unsigned int paging_max_paddr_bits(const
> struct domain *d)
> unsigned int bits = paging_mode_hap(d) ? hap_paddr_bits : paddr_bits;
>
> if ( !IS_ENABLED(BIGMEM) && paging_mode_shadow(d) &&
> - (!is_pv_domain(d) || opt_allow_superpage) )
> + !is_pv_domain(d) )
Reflow onto the previous line?
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |