|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled
On Fri, Feb 13, 2026 at 02:37:29PM +0100, Alejandro Vallejo wrote:
> PV-shim already has hvm_enabled optimised to false, but there's no
> reason HVM-only builds can't benefit from the same optimisation as long
> as we add a boot-time panic in case HVM support is missed. Many branches
> go away, some in the potentially hot switch_cr3_cr4.
>
> HVM-only:
> add/remove: 0/1 grow/shrink: 1/9 up/down: 1/-162 (-161)
> Function old new delta
> arch_do_physinfo 79 80 +1
> hvm_enabled 1 - -1
> symbols_offsets 30732 30728 -4
> symbols_names 108029 108022 -7
> symbols_sorted_offsets 60656 60648 -8
> flush_area_local 571 562 -9
> switch_cr3_cr4 311 300 -11
> init_xen_cap_info 62 43 -19
> arch_sanitise_domain_config 885 863 -22
> init_guest_cpu_policies 1270 1247 -23
> hvm_domain_initialise 1127 1069 -58
> Total: Before=3797004, After=3796843, chg -0.00%
>
> With hvm_enabled const-ified, it's fine to take hvm_flush_guest_tlbs()
> outside the CONFIG_HVM ifdef and remove the stub. They compile to the
> same code after DCE.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
> ---
> xen/arch/x86/hvm/hvm.c | 9 +++++++++
> xen/arch/x86/include/asm/hvm/hvm.h | 30 +++++++++++++++---------------
> 2 files changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 4d37a93c57..da56944e74 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -72,7 +72,9 @@
>
> #include <compat/hvm/hvm_op.h>
>
> +#ifdef CONFIG_PV
> bool __read_mostly hvm_enabled;
__ro_after_init?
> +#endif /* CONFIG_PV */
>
> #ifdef DBG_LEVEL_0
> unsigned int opt_hvm_debug_level __read_mostly;
> @@ -173,9 +175,16 @@ static int __init cf_check hvm_enable(void)
> svm_fill_funcs();
>
> if ( fns == NULL )
> + {
> + if ( !IS_ENABLED(CONFIG_PV) )
> + panic("HVM support not detected and PV compiled-out\n");
> +
> return 0;
> + }
>
> +#ifdef CONFIG_PV
CONFIG_HVM I think?
> hvm_enabled = 1;
= true;
> +#endif /* CONFIG_PV */
>
> printk("HVM: %s enabled\n", fns->name);
> if ( !hap_supported(&hvm_funcs) )
> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h
> b/xen/arch/x86/include/asm/hvm/hvm.h
> index 7d9774df59..dc609bf4cb 100644
> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -261,7 +261,11 @@ struct hvm_function_table {
> };
>
> extern struct hvm_function_table hvm_funcs;
> +#if defined(CONFIG_PV) && defined(CONFIG_HVM)
> extern bool hvm_enabled;
> +#else
> +#define hvm_enabled IS_ENABLED(CONFIG_HVM)
> +#endif
> extern int8_t hvm_port80_allowed;
>
> extern const struct hvm_function_table *start_svm(void);
> @@ -399,6 +403,17 @@ static inline bool using_svm(void)
> #define hvm_is_in_uc_mode(d) \
> (using_vmx() && (d)->arch.hvm.vmx.in_uc_mode)
>
> +/*
> + * Called to ensure than all guest-specific mappings in a tagged TLB are
> + * flushed; does *not* flush Xen's TLB entries, and on processors without a
> + * tagged TLB it will be a noop.
> + */
> +static inline void hvm_flush_guest_tlbs(void)
> +{
> + if ( hvm_enabled )
> + hvm_asid_flush_core();
> +}
> +
> #ifdef CONFIG_HVM
>
> #define hvm_get_guest_tsc(v) hvm_get_guest_tsc_fixed(v, 0)
> @@ -498,17 +513,6 @@ static inline void hvm_set_tsc_offset(struct vcpu *v,
> uint64_t offset)
> alternative_vcall(hvm_funcs.set_tsc_offset, v, offset);
> }
>
> -/*
> - * Called to ensure than all guest-specific mappings in a tagged TLB are
> - * flushed; does *not* flush Xen's TLB entries, and on processors without a
> - * tagged TLB it will be a noop.
> - */
> -static inline void hvm_flush_guest_tlbs(void)
> -{
> - if ( hvm_enabled )
> - hvm_asid_flush_core();
> -}
Is there any specific reason you only pick hvm_flush_guest_tlbs().
Given what you do with hvm_enabled you could probably generalize all
the dummy helpers in the !CONFIG_HVM section now?
Thanks, Roger.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |