From: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: <xen-devel@lists.xenproject.org>, Jan Beulich <jbeulich@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled
Date: Fri, 13 Feb 2026 18:04:33 +0100 [thread overview]
Message-ID: <DGDZWSLET8UI.3AMV83AW7Z3I0@amd.com> (raw)
In-Reply-To: <aY80qJVIZOjjqBOS@Mac.lan>
On Fri Feb 13, 2026 at 3:26 PM CET, Roger Pau Monné wrote:
> 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@amd.com>
>> ---
>> 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?
Yeah, seems to have been missing originally
>
>> +#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?
No. CONFIG_HVM always holds here, what we want to remove is hvm_enabled being
present when CONFIG_PV is _also_ present.
>
>> hvm_enabled = 1;
>
> = true;
True enough.
>
>> +#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().
I didn't try to remove more. That one was the only one with hvm_enabled in the
static inline so it seems easy to pick apart.
I just tried compiling and I require very few additions to make the build
compile without stubs. I'll send another version with the adjustments needed.
Cheers,
Alejandro
next prev parent reply other threads:[~2026-02-13 17:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 13:37 [PATCH 0/2] x86: Const-ify hvm_enabled and hap_enabled() when possible Alejandro Vallejo
2026-02-13 13:37 ` [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled Alejandro Vallejo
2026-02-13 14:26 ` Roger Pau Monné
2026-02-13 16:01 ` Andrew Cooper
2026-02-13 16:33 ` Roger Pau Monné
2026-02-13 17:04 ` Alejandro Vallejo [this message]
2026-02-13 18:30 ` Roger Pau Monné
2026-02-13 13:37 ` [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out Alejandro Vallejo
2026-02-13 15:09 ` Roger Pau Monné
2026-02-13 17:30 ` Alejandro Vallejo
2026-02-13 18:42 ` Roger Pau Monné
2026-02-13 19:13 ` Alejandro Vallejo
2026-02-13 19:54 ` Roger Pau Monné
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DGDZWSLET8UI.3AMV83AW7Z3I0@amd.com \
--to=alejandro.garciavallejo@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.