[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


  • To: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 13 Feb 2026 19:30:19 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4vmO6QHuz+sL8Fav308qwPIEi45MlodPL7zNWc4BqI4=; b=RHrZTTe3lFJdAvuTd6qmXoSR9Gwse8SRO1HQNNprTx8nerf94tZ9Nz5z3l3dmK8Ghg73ddkyRswiokSZfcVsBjyqYjomYmAAOT10pjPyNZrxF2dYIGsQHcX0HfaKfSiM8OdpZwBTibxkNzbzypVnrXTZChPqBfWVPjrFkzWjHy2M0x5+Z2YaLjmhQqbzg5vdvTUXFih8Y4B9VdoFxhq+N1Txm48qBSOE1V+2fVJ8DL0/AnsjBR+6NRoC0uP/W1nJhjfPiLZdGJy2sSNWdnESxMOfUzeFP8EhwqG4oHt/6vTmCewoNGMQKK1zrqZadiWr3KD5Luc302P1YZKf04+m7Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bh9Da2Qtb2bKijI3XsXo9fCX9fYzHnWXhQEfDHabcANQLYOK8FZEbb7Ut5l9wSSjF+aIf0G8h/Aleip2/AxvXsxK2hM9LDD7Y3WJcMbV5Q49FV37Hf0oarr0TajRG6bcDF418OzJCyIq8vbb9y26jbUdSTPJfH9ulMRo+QEG9RY9MW24FB0tS33BtHB9jiK0J6P9pgGR+8rAHBZlIjdZdBFGBfqQEnWS10OVZGWd97yaYfzseZTDLqH8sHVnk3PGwo+7Bh6V0exyVBIYwmwAQsAukHHl3/JT9XrhxGtASJCHd7YdxEM9MesZ1I58lWb+lrynC9uf+T3nzFfHEA9ZMA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Fri, 13 Feb 2026 18:30:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Feb 13, 2026 at 06:04:33PM +0100, Alejandro Vallejo wrote:
> 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@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?
> 
> Yeah, seems to have been missing originally

I bet __ro_after_init wasn't available when this was introduced.

> >
> >> +#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.

Yeah, Andrew already noticed that.

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

Oh, I see.  That one already had the hvm_enabled condition in it's
non-stub version.

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

OK, I think if we could unify them that would make the header smaller
and easier to read.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.