[PATCH 0/2] x86: Const-ify hvm_enabled and hap_enabled() when possible

[PATCH 0/2] x86: Const-ify hvm_enabled and hap_enabled() when possible

[Alejandro Vallejo]

Hi,

pipeline (green): https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2324325987

hvm_enabled is already a constant in PV-only builds. Patch 1 makes it so it's
also a constant in HVM-only builds (with a compile-time panic if HVM support
is lacking in HW). Patch 2 makes it so HVM-only shadowless builds mandate HAP
at boot, thus const-ifying hap_enabled() too and removing that pesky shadow/
folder.

Cheers,
Alejandro

Alejandro Vallejo (2):
  x86: Make hvm_enabled a constant unless both PV and HVM are both
    compiled
  x86: Force HAP to be enabled when PV and shadow paging are compiled
    out

 xen/arch/x86/Kconfig               |  2 ++
 xen/arch/x86/hvm/Kconfig           |  3 +++
 xen/arch/x86/hvm/hvm.c             | 17 ++++++++++++++++
 xen/arch/x86/include/asm/hvm/hvm.h | 32 +++++++++++++++---------------
 xen/arch/x86/mm/Makefile           |  2 +-
 xen/include/xen/sched.h            |  3 +++
 6 files changed, 42 insertions(+), 17 deletions(-)


base-commit: 1f4f85b64d393be1aa8dc8170201f4fbfe9c7222
-- 
2.43.0

[PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled

[Alejandro Vallejo]

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;
+#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
     hvm_enabled = 1;
+#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();
-}
-
 static inline unsigned int
 hvm_get_cpl(struct vcpu *v)
 {
@@ -854,8 +858,6 @@ static inline void hvm_sync_pir_to_irr(struct vcpu *v)
 
 #else  /* CONFIG_HVM */
 
-#define hvm_enabled false
-
 /*
  * List of inline functions above, of which only declarations are
  * needed because DCE will kick in.
@@ -902,8 +904,6 @@ static inline int hvm_cpu_up(void)
 
 static inline void hvm_cpu_down(void) {}
 
-static inline void hvm_flush_guest_tlbs(void) {}
-
 static inline void hvm_invlpg(const struct vcpu *v, unsigned long linear)
 {
     ASSERT_UNREACHABLE();
-- 
2.43.0

Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled

[Roger Pau Monné]

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?

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

Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled

[Andrew Cooper]

On 13/02/2026 2:26 pm, Roger Pau Monné wrote:
> On Fri, Feb 13, 2026 at 02:37:29PM +0100, Alejandro Vallejo wrote:
>> 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
>> @@ -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");

As with Rogers feedback on the next patch, this wording isn't ideal. 
How about:

"HVM support required but not available\n".

This is reachable for people who use cpuid=no-vmx,no-svm but they get to
keep all the pieces and the documentation already has a general warning
about this kind of stuff.

>> +
>>          return 0;
>> +    }
>>  
>> +#ifdef CONFIG_PV
> CONFIG_HVM I think?

No - CONFIG_PV is correct here, because we're inside an HVM-only file. 
It's the only case where this variable exists for real.

~Andrew

Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled

[Roger Pau Monné]

On Fri, Feb 13, 2026 at 04:01:25PM +0000, Andrew Cooper wrote:
> On 13/02/2026 2:26 pm, Roger Pau Monné wrote:
> > On Fri, Feb 13, 2026 at 02:37:29PM +0100, Alejandro Vallejo wrote:
> >> 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
> >> @@ -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");
> 
> As with Rogers feedback on the next patch, this wording isn't ideal. 
> How about:
> 
> "HVM support required but not available\n".
> 
> This is reachable for people who use cpuid=no-vmx,no-svm but they get to
> keep all the pieces and the documentation already has a general warning
> about this kind of stuff.

Hm, yes, I forgot to comment on this one.

> 
> >> +
> >>          return 0;
> >> +    }
> >>  
> >> +#ifdef CONFIG_PV
> > CONFIG_HVM I think?
> 
> No - CONFIG_PV is correct here, because we're inside an HVM-only file. 
> It's the only case where this variable exists for real.

Oh, I see.  Yes, those are the right guards, otherwise the variable is
hardcoded to IS_ENABLED(CONFIG_HVM).  Sorry, my bad.  It's a bit ugly
to have to do it with such ifdefs, but right now I don't see a better
way.

Thanks, Roger.

Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled

[Alejandro Vallejo]

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

Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled

[Roger Pau Monné]

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

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.

[PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out

[Alejandro Vallejo]

Makes hap_enabled() a compile-time constant. This removes a number
of hooks that normally go reach onto shadow paging code, clears
many branches in a number of places and generally improves codegen
throughout.

Take the chance to fully remove the shadow/ folder as it's now fully
compiled out.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
bloat-o-meter against prior commit (defconfig:-pv,-shadow on both):

  add/remove: 0/12 grow/shrink: 2/31 up/down: 67/-1609 (-1542)
  Function                                     old     new   delta
  unmap_mmio_regions                          1340    1374     +34
  map_mmio_regions                             211     244     +33
  opt_hap_enabled                                1       -      -1
  shadow_vcpu_init                               2       -      -2
  __setup_str_opt_hap_enabled                    4       -      -4
  _update_paging_modes                           6       -      -6
  _toggle_log_dirty                              6       -      -6
  _clean_dirty_bitmap                            6       -      -6
  cpuid_viridian_leaves                        728     714     -14
  iommu_domain_init                            291     276     -15
  p2m_pt_change_entry_type_global              214     198     -16
  paging_teardown                               91      74     -17
  paging_set_allocation                        384     367     -17
  paging_enable                                 76      59     -17
  p2m_init_one                                 295     278     -17
  ept_sync_domain                              201     184     -17
  arch_set_paging_mempool_size                 437     420     -17
  p2m_free_one                                  78      59     -19
  paging_vcpu_teardown                          36      15     -21
  p2m_pt_init                                  125     104     -21
  p2m_pt_change_entry_type_range               218     197     -21
  arch_do_physinfo                              76      53     -23
  sh_none_ops                                   24       -     -24
  paging_final_teardown                        134     110     -24
  __setup_opt_hap_enabled                       24       -     -24
  paging_vcpu_init                              41      15     -26
  paging_domain_init                           167     141     -26
  p2m_mem_access_sanity_check                   71      42     -29
  hvm_enable                                   449     419     -30
  init_guest_cpu_policies                     1247    1213     -34
  paging_domctl                               3357    3318     -39
  __start_xen                                 9456    9416     -40
  arch_sanitise_domain_config                  794     747     -47
  symbols_offsets                            29636   29588     -48
  p2m_set_entry                                305     247     -58
  guest_cpuid                                 1919    1858     -61
  ept_dump_p2m_table                           817     751     -66
  recalculate_cpuid_policy                     874     806     -68
  shadow_domain_init                            71       -     -71
  mmio_order                                    73       -     -73
  hvm_shadow_max_featuremask                    76       -     -76
  hvm_shadow_def_featuremask                    76       -     -76
  dm_op                                       3594    3510     -84
  symbols_sorted_offsets                     58464   58368     -96
  symbols_names                             103425  103213    -212
  Total: Before=3644618, After=3643076, chg -0.04%
---
 xen/arch/x86/Kconfig               | 2 ++
 xen/arch/x86/hvm/Kconfig           | 3 +++
 xen/arch/x86/hvm/hvm.c             | 8 ++++++++
 xen/arch/x86/include/asm/hvm/hvm.h | 2 +-
 xen/arch/x86/mm/Makefile           | 2 +-
 xen/include/xen/sched.h            | 3 +++
 6 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 2ce4747f6e..190f419720 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -67,6 +67,7 @@ source "arch/Kconfig"
 config PV
 	def_bool y
 	prompt "PV support"
+	select OPT_HAP
 	help
 	  Interfaces to support PV domains. These require guest kernel support
 	  to run as a PV guest, but don't require any specific hardware support.
@@ -147,6 +148,7 @@ config SHADOW_PAGING
 	bool "Shadow Paging"
 	default !PV_SHIM_EXCLUSIVE
 	depends on PV || HVM
+	select OPT_HAP
 	help
 	  Shadow paging is a software alternative to hardware paging support
 	  (Intel EPT, AMD NPT).
diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
index f32bf5cbb7..310e09847b 100644
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -92,4 +92,7 @@ config MEM_SHARING
 	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
 	depends on INTEL_VMX
 
+config OPT_HAP
+	bool
+
 endif
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index da56944e74..ce58632b02 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -91,9 +91,11 @@ struct hvm_function_table __ro_after_init hvm_funcs;
 unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE)
     hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG];
 
+#ifdef CONFIG_OPT_HAP
 /* Xen command-line option to enable HAP */
 static bool __initdata opt_hap_enabled = true;
 boolean_param("hap", opt_hap_enabled);
+#endif /* CONFIG_OPT_HAP */
 
 #ifndef opt_hvm_fep
 /* Permit use of the Forced Emulation Prefix in HVM guests */
@@ -144,15 +146,21 @@ static bool __init hap_supported(struct hvm_function_table *fns)
     if ( !fns->caps.hap )
     {
         printk("HVM: Hardware Assisted Paging (HAP) not detected\n");
+
+        if ( !IS_ENABLED(CONFIG_OPT_HAP) )
+            panic("HAP is compile-time mandatory\n");
+
         return false;
     }
 
+#ifdef CONFIG_OPT_HAP
     if ( !opt_hap_enabled )
     {
         fns->caps.hap = false;
         printk("HVM: Hardware Assisted Paging (HAP) detected but disabled\n");
         return false;
     }
+#endif /* CONFIG_OPT_HAP */
 
     return true;
 }
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index dc609bf4cb..b330d65d6d 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -703,7 +703,7 @@ static inline bool hvm_is_singlestep_supported(void)
 
 static inline bool hvm_hap_supported(void)
 {
-    return hvm_funcs.caps.hap;
+    return !IS_ENABLED(CONFIG_OPT_HAP) ?: hvm_funcs.caps.hap;
 }
 
 /* returns true if hardware supports alternate p2m's */
diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index 960f6e8409..64fde82c50 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -1,4 +1,4 @@
-obj-y += shadow/
+obj-$(CONFIG_OPT_HAP) += shadow/
 obj-$(CONFIG_HVM) += hap/
 
 obj-$(CONFIG_ALTP2M) += altp2m.o
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 1268632344..0e317504f7 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1220,6 +1220,9 @@ static always_inline bool is_hvm_vcpu(const struct vcpu *v)
 
 static always_inline bool hap_enabled(const struct domain *d)
 {
+    if ( !IS_ENABLED(CONFIG_OPT_HAP) )
+        return true;
+
     /* sanitise_domain_config() rejects HAP && !HVM */
     return IS_ENABLED(CONFIG_HVM) &&
         evaluate_nospec(d->options & XEN_DOMCTL_CDF_hap);
-- 
2.43.0

Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out

[Roger Pau Monné]

On Fri, Feb 13, 2026 at 02:37:30PM +0100, Alejandro Vallejo wrote:
> Makes hap_enabled() a compile-time constant. This removes a number
> of hooks that normally go reach onto shadow paging code, clears
> many branches in a number of places and generally improves codegen
> throughout.
> 
> Take the chance to fully remove the shadow/ folder as it's now fully
> compiled out.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
> bloat-o-meter against prior commit (defconfig:-pv,-shadow on both):
> 
>   add/remove: 0/12 grow/shrink: 2/31 up/down: 67/-1609 (-1542)
>   Function                                     old     new   delta
>   unmap_mmio_regions                          1340    1374     +34
>   map_mmio_regions                             211     244     +33
>   opt_hap_enabled                                1       -      -1
>   shadow_vcpu_init                               2       -      -2
>   __setup_str_opt_hap_enabled                    4       -      -4
>   _update_paging_modes                           6       -      -6
>   _toggle_log_dirty                              6       -      -6
>   _clean_dirty_bitmap                            6       -      -6
>   cpuid_viridian_leaves                        728     714     -14
>   iommu_domain_init                            291     276     -15
>   p2m_pt_change_entry_type_global              214     198     -16
>   paging_teardown                               91      74     -17
>   paging_set_allocation                        384     367     -17
>   paging_enable                                 76      59     -17
>   p2m_init_one                                 295     278     -17
>   ept_sync_domain                              201     184     -17
>   arch_set_paging_mempool_size                 437     420     -17
>   p2m_free_one                                  78      59     -19
>   paging_vcpu_teardown                          36      15     -21
>   p2m_pt_init                                  125     104     -21
>   p2m_pt_change_entry_type_range               218     197     -21
>   arch_do_physinfo                              76      53     -23
>   sh_none_ops                                   24       -     -24
>   paging_final_teardown                        134     110     -24
>   __setup_opt_hap_enabled                       24       -     -24
>   paging_vcpu_init                              41      15     -26
>   paging_domain_init                           167     141     -26
>   p2m_mem_access_sanity_check                   71      42     -29
>   hvm_enable                                   449     419     -30
>   init_guest_cpu_policies                     1247    1213     -34
>   paging_domctl                               3357    3318     -39
>   __start_xen                                 9456    9416     -40
>   arch_sanitise_domain_config                  794     747     -47
>   symbols_offsets                            29636   29588     -48
>   p2m_set_entry                                305     247     -58
>   guest_cpuid                                 1919    1858     -61
>   ept_dump_p2m_table                           817     751     -66
>   recalculate_cpuid_policy                     874     806     -68
>   shadow_domain_init                            71       -     -71
>   mmio_order                                    73       -     -73
>   hvm_shadow_max_featuremask                    76       -     -76
>   hvm_shadow_def_featuremask                    76       -     -76
>   dm_op                                       3594    3510     -84
>   symbols_sorted_offsets                     58464   58368     -96
>   symbols_names                             103425  103213    -212
>   Total: Before=3644618, After=3643076, chg -0.04%
> ---
>  xen/arch/x86/Kconfig               | 2 ++
>  xen/arch/x86/hvm/Kconfig           | 3 +++
>  xen/arch/x86/hvm/hvm.c             | 8 ++++++++
>  xen/arch/x86/include/asm/hvm/hvm.h | 2 +-
>  xen/arch/x86/mm/Makefile           | 2 +-
>  xen/include/xen/sched.h            | 3 +++
>  6 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 2ce4747f6e..190f419720 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -67,6 +67,7 @@ source "arch/Kconfig"
>  config PV
>  	def_bool y
>  	prompt "PV support"
> +	select OPT_HAP
>  	help
>  	  Interfaces to support PV domains. These require guest kernel support
>  	  to run as a PV guest, but don't require any specific hardware support.
> @@ -147,6 +148,7 @@ config SHADOW_PAGING
>  	bool "Shadow Paging"
>  	default !PV_SHIM_EXCLUSIVE
>  	depends on PV || HVM
> +	select OPT_HAP
>  	help
>  	  Shadow paging is a software alternative to hardware paging support
>  	  (Intel EPT, AMD NPT).
> diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
> index f32bf5cbb7..310e09847b 100644
> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -92,4 +92,7 @@ config MEM_SHARING
>  	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
>  	depends on INTEL_VMX
>  
> +config OPT_HAP
> +	bool

Can't you define this outside of Kconfig, like:

#define HAP_ONLY_BUILD (!IS_ENABLED(CONFIG_PV) && !IS_ENABLED(CONFIG_SHADOW_PAGING))

HAP_ONLY_BUILD is likely not the best name.  Maybe CONFIG_HAP_REQUIRED
or some such?  (Seeing the usage below)

FWIW, with the current naming I've assume this was supposed to mean
"Option HAP" or some such, when is "HAP is Optional".  We usually use
"opt" as a shortcut for "option" in several places on the Xen code
base, like "opt_hap_enabled".  I also think using it in the positive
for so the variable meaning "required" instead of "optional" makes
some of the logic easier to follow below.

>  endif
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index da56944e74..ce58632b02 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -91,9 +91,11 @@ struct hvm_function_table __ro_after_init hvm_funcs;
>  unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE)
>      hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG];
>  
> +#ifdef CONFIG_OPT_HAP
>  /* Xen command-line option to enable HAP */
>  static bool __initdata opt_hap_enabled = true;
>  boolean_param("hap", opt_hap_enabled);
> +#endif /* CONFIG_OPT_HAP */

Hm, if you nuke the option like that, it needs to be reflected in
xen-command-line.pandoc document.

>  
>  #ifndef opt_hvm_fep
>  /* Permit use of the Forced Emulation Prefix in HVM guests */
> @@ -144,15 +146,21 @@ static bool __init hap_supported(struct hvm_function_table *fns)
>      if ( !fns->caps.hap )
>      {
>          printk("HVM: Hardware Assisted Paging (HAP) not detected\n");
> +
> +        if ( !IS_ENABLED(CONFIG_OPT_HAP) )
> +            panic("HAP is compile-time mandatory\n");

From a user perspective, it's a weird error message IMO.  I would
rather say:

"HVM: Hardware Assisted Paging (HAP) is mandatory but not detected\n".

Not fully convinced about that wording, but I would certainly drop the
"compile-time" part of yours.  A user is not likely to care/know about
compile-time subtlety of the error message.

> +
>          return false;
>      }
>  
> +#ifdef CONFIG_OPT_HAP
>      if ( !opt_hap_enabled )

You could possibly do:

#ifdef CONFIG_OPT_HAP
/* Xen command-line option to enable HAP */
static bool __initdata opt_hap_enabled = true;
boolean_param("hap", opt_hap_enabled);
#else /* CONFIG_OPT_HAP */
# define opt_hap_enabled true
#endif /* !CONFIG_OPT_HAP */

Above, and avoid the ifdefs here?

>      {
>          fns->caps.hap = false;
>          printk("HVM: Hardware Assisted Paging (HAP) detected but disabled\n");
>          return false;
>      }
> +#endif /* CONFIG_OPT_HAP */
>  
>      return true;
>  }
> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
> index dc609bf4cb..b330d65d6d 100644
> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -703,7 +703,7 @@ static inline bool hvm_is_singlestep_supported(void)
>  
>  static inline bool hvm_hap_supported(void)
>  {
> -    return hvm_funcs.caps.hap;
> +    return !IS_ENABLED(CONFIG_OPT_HAP) ?: hvm_funcs.caps.hap;

return CONFIG_HAP_REQUIRED ?: hvm_funcs.caps.hap;

IMO is easier to read (same below for the hap_enabled() early return).

>  }
>  
>  /* returns true if hardware supports alternate p2m's */
> diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
> index 960f6e8409..64fde82c50 100644
> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += shadow/
> +obj-$(CONFIG_OPT_HAP) += shadow/

I think you can use:

obj-$(findstring y,$(CONFIG_PV) $(CONFIG_SHADOW_PAGING)) += ...

Thanks, Roger.

Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out

[Alejandro Vallejo]

On Fri Feb 13, 2026 at 4:09 PM CET, Roger Pau Monné wrote:
> On Fri, Feb 13, 2026 at 02:37:30PM +0100, Alejandro Vallejo wrote:
>> Makes hap_enabled() a compile-time constant. This removes a number
>> of hooks that normally go reach onto shadow paging code, clears
>> many branches in a number of places and generally improves codegen
>> throughout.
>> 
>> Take the chance to fully remove the shadow/ folder as it's now fully
>> compiled out.
>> 
>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>> ---
>> bloat-o-meter against prior commit (defconfig:-pv,-shadow on both):
>> 
>>   add/remove: 0/12 grow/shrink: 2/31 up/down: 67/-1609 (-1542)
>>   Function                                     old     new   delta
>>   unmap_mmio_regions                          1340    1374     +34
>>   map_mmio_regions                             211     244     +33
>>   opt_hap_enabled                                1       -      -1
>>   shadow_vcpu_init                               2       -      -2
>>   __setup_str_opt_hap_enabled                    4       -      -4
>>   _update_paging_modes                           6       -      -6
>>   _toggle_log_dirty                              6       -      -6
>>   _clean_dirty_bitmap                            6       -      -6
>>   cpuid_viridian_leaves                        728     714     -14
>>   iommu_domain_init                            291     276     -15
>>   p2m_pt_change_entry_type_global              214     198     -16
>>   paging_teardown                               91      74     -17
>>   paging_set_allocation                        384     367     -17
>>   paging_enable                                 76      59     -17
>>   p2m_init_one                                 295     278     -17
>>   ept_sync_domain                              201     184     -17
>>   arch_set_paging_mempool_size                 437     420     -17
>>   p2m_free_one                                  78      59     -19
>>   paging_vcpu_teardown                          36      15     -21
>>   p2m_pt_init                                  125     104     -21
>>   p2m_pt_change_entry_type_range               218     197     -21
>>   arch_do_physinfo                              76      53     -23
>>   sh_none_ops                                   24       -     -24
>>   paging_final_teardown                        134     110     -24
>>   __setup_opt_hap_enabled                       24       -     -24
>>   paging_vcpu_init                              41      15     -26
>>   paging_domain_init                           167     141     -26
>>   p2m_mem_access_sanity_check                   71      42     -29
>>   hvm_enable                                   449     419     -30
>>   init_guest_cpu_policies                     1247    1213     -34
>>   paging_domctl                               3357    3318     -39
>>   __start_xen                                 9456    9416     -40
>>   arch_sanitise_domain_config                  794     747     -47
>>   symbols_offsets                            29636   29588     -48
>>   p2m_set_entry                                305     247     -58
>>   guest_cpuid                                 1919    1858     -61
>>   ept_dump_p2m_table                           817     751     -66
>>   recalculate_cpuid_policy                     874     806     -68
>>   shadow_domain_init                            71       -     -71
>>   mmio_order                                    73       -     -73
>>   hvm_shadow_max_featuremask                    76       -     -76
>>   hvm_shadow_def_featuremask                    76       -     -76
>>   dm_op                                       3594    3510     -84
>>   symbols_sorted_offsets                     58464   58368     -96
>>   symbols_names                             103425  103213    -212
>>   Total: Before=3644618, After=3643076, chg -0.04%
>> ---
>>  xen/arch/x86/Kconfig               | 2 ++
>>  xen/arch/x86/hvm/Kconfig           | 3 +++
>>  xen/arch/x86/hvm/hvm.c             | 8 ++++++++
>>  xen/arch/x86/include/asm/hvm/hvm.h | 2 +-
>>  xen/arch/x86/mm/Makefile           | 2 +-
>>  xen/include/xen/sched.h            | 3 +++
>>  6 files changed, 18 insertions(+), 2 deletions(-)
>> 
>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>> index 2ce4747f6e..190f419720 100644
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -67,6 +67,7 @@ source "arch/Kconfig"
>>  config PV
>>  	def_bool y
>>  	prompt "PV support"
>> +	select OPT_HAP
>>  	help
>>  	  Interfaces to support PV domains. These require guest kernel support
>>  	  to run as a PV guest, but don't require any specific hardware support.
>> @@ -147,6 +148,7 @@ config SHADOW_PAGING
>>  	bool "Shadow Paging"
>>  	default !PV_SHIM_EXCLUSIVE
>>  	depends on PV || HVM
>> +	select OPT_HAP
>>  	help
>>  	  Shadow paging is a software alternative to hardware paging support
>>  	  (Intel EPT, AMD NPT).
>> diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
>> index f32bf5cbb7..310e09847b 100644
>> --- a/xen/arch/x86/hvm/Kconfig
>> +++ b/xen/arch/x86/hvm/Kconfig
>> @@ -92,4 +92,7 @@ config MEM_SHARING
>>  	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
>>  	depends on INTEL_VMX
>>  
>> +config OPT_HAP
>> +	bool
>
> Can't you define this outside of Kconfig, like:
>
> #define HAP_ONLY_BUILD (!IS_ENABLED(CONFIG_PV) && !IS_ENABLED(CONFIG_SHADOW_PAGING))

Sure.

>
> HAP_ONLY_BUILD is likely not the best name.  Maybe CONFIG_HAP_REQUIRED
> or some such?  (Seeing the usage below)

Definitely not CONFIG_*, or it'd be an accident about to happen when mistakenly
used on IS_ENABLED(). HAP_EXCLUSIVE?

>
> FWIW, with the current naming I've assume this was supposed to mean
> "Option HAP" or some such, when is "HAP is Optional".  We usually use

It was. Originally it had a help message and a default, but I quickly noticed
that served no purpose. It has that weird polarity so the build would remain
with new options being additive only.

In retrospect it can go back to a more natural HAP_EXCLUSIVE that removes
a bunch of !s in the code.

> "opt" as a shortcut for "option" in several places on the Xen code
> base, like "opt_hap_enabled".  I also think using it in the positive
> for so the variable meaning "required" instead of "optional" makes
> some of the logic easier to follow below.

It does, but in Kconfig it's nicer if an option being enabled yields a strictly
more capable hypervisor, I think. Makes allyesconfig and allnoconfig work as
intended.

>
>>  endif
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index da56944e74..ce58632b02 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -91,9 +91,11 @@ struct hvm_function_table __ro_after_init hvm_funcs;
>>  unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE)
>>      hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG];
>>  
>> +#ifdef CONFIG_OPT_HAP
>>  /* Xen command-line option to enable HAP */
>>  static bool __initdata opt_hap_enabled = true;
>>  boolean_param("hap", opt_hap_enabled);
>> +#endif /* CONFIG_OPT_HAP */
>
> Hm, if you nuke the option like that, it needs to be reflected in
> xen-command-line.pandoc document.

Ack.

>
>>  
>>  #ifndef opt_hvm_fep
>>  /* Permit use of the Forced Emulation Prefix in HVM guests */
>> @@ -144,15 +146,21 @@ static bool __init hap_supported(struct hvm_function_table *fns)
>>      if ( !fns->caps.hap )
>>      {
>>          printk("HVM: Hardware Assisted Paging (HAP) not detected\n");
>> +
>> +        if ( !IS_ENABLED(CONFIG_OPT_HAP) )
>> +            panic("HAP is compile-time mandatory\n");
>
> From a user perspective, it's a weird error message IMO.  I would
> rather say:
>
> "HVM: Hardware Assisted Paging (HAP) is mandatory but not detected\n".
>
> Not fully convinced about that wording, but I would certainly drop the
> "compile-time" part of yours.  A user is not likely to care/know about
> compile-time subtlety of the error message.

Sure.

>
>> +
>>          return false;
>>      }
>>  
>> +#ifdef CONFIG_OPT_HAP
>>      if ( !opt_hap_enabled )
>
> You could possibly do:
>
> #ifdef CONFIG_OPT_HAP
> /* Xen command-line option to enable HAP */
> static bool __initdata opt_hap_enabled = true;
> boolean_param("hap", opt_hap_enabled);
> #else /* CONFIG_OPT_HAP */
> # define opt_hap_enabled true
> #endif /* !CONFIG_OPT_HAP */
>
> Above, and avoid the ifdefs here?

Whatever poison you prefer. It's just ugliness motion.

>
>>      {
>>          fns->caps.hap = false;
>>          printk("HVM: Hardware Assisted Paging (HAP) detected but disabled\n");
>>          return false;
>>      }
>> +#endif /* CONFIG_OPT_HAP */
>>  
>>      return true;
>>  }
>> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
>> index dc609bf4cb..b330d65d6d 100644
>> --- a/xen/arch/x86/include/asm/hvm/hvm.h
>> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
>> @@ -703,7 +703,7 @@ static inline bool hvm_is_singlestep_supported(void)
>>  
>>  static inline bool hvm_hap_supported(void)
>>  {
>> -    return hvm_funcs.caps.hap;
>> +    return !IS_ENABLED(CONFIG_OPT_HAP) ?: hvm_funcs.caps.hap;
>
> return CONFIG_HAP_REQUIRED ?: hvm_funcs.caps.hap;
>
> IMO is easier to read (same below for the hap_enabled() early return).
>
>>  }
>>  
>>  /* returns true if hardware supports alternate p2m's */
>> diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
>> index 960f6e8409..64fde82c50 100644
>> --- a/xen/arch/x86/mm/Makefile
>> +++ b/xen/arch/x86/mm/Makefile
>> @@ -1,4 +1,4 @@
>> -obj-y += shadow/
>> +obj-$(CONFIG_OPT_HAP) += shadow/
>
> I think you can use:
>
> obj-$(findstring y,$(CONFIG_PV) $(CONFIG_SHADOW_PAGING)) += ...

Hmmm. I guess I shouldn't just include it twice, like we do for other .o files.

Cheers,
Alejandro

Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out

[Roger Pau Monné]

On Fri, Feb 13, 2026 at 06:30:54PM +0100, Alejandro Vallejo wrote:
> On Fri Feb 13, 2026 at 4:09 PM CET, Roger Pau Monné wrote:
> > On Fri, Feb 13, 2026 at 02:37:30PM +0100, Alejandro Vallejo wrote:
> >> Makes hap_enabled() a compile-time constant. This removes a number
> >> of hooks that normally go reach onto shadow paging code, clears
> >> many branches in a number of places and generally improves codegen
> >> throughout.
> >> 
> >> Take the chance to fully remove the shadow/ folder as it's now fully
> >> compiled out.
> >> 
> >> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> >> ---
> >> bloat-o-meter against prior commit (defconfig:-pv,-shadow on both):
> >> 
> >>   add/remove: 0/12 grow/shrink: 2/31 up/down: 67/-1609 (-1542)
> >>   Function                                     old     new   delta
> >>   unmap_mmio_regions                          1340    1374     +34
> >>   map_mmio_regions                             211     244     +33
> >>   opt_hap_enabled                                1       -      -1
> >>   shadow_vcpu_init                               2       -      -2
> >>   __setup_str_opt_hap_enabled                    4       -      -4
> >>   _update_paging_modes                           6       -      -6
> >>   _toggle_log_dirty                              6       -      -6
> >>   _clean_dirty_bitmap                            6       -      -6
> >>   cpuid_viridian_leaves                        728     714     -14
> >>   iommu_domain_init                            291     276     -15
> >>   p2m_pt_change_entry_type_global              214     198     -16
> >>   paging_teardown                               91      74     -17
> >>   paging_set_allocation                        384     367     -17
> >>   paging_enable                                 76      59     -17
> >>   p2m_init_one                                 295     278     -17
> >>   ept_sync_domain                              201     184     -17
> >>   arch_set_paging_mempool_size                 437     420     -17
> >>   p2m_free_one                                  78      59     -19
> >>   paging_vcpu_teardown                          36      15     -21
> >>   p2m_pt_init                                  125     104     -21
> >>   p2m_pt_change_entry_type_range               218     197     -21
> >>   arch_do_physinfo                              76      53     -23
> >>   sh_none_ops                                   24       -     -24
> >>   paging_final_teardown                        134     110     -24
> >>   __setup_opt_hap_enabled                       24       -     -24
> >>   paging_vcpu_init                              41      15     -26
> >>   paging_domain_init                           167     141     -26
> >>   p2m_mem_access_sanity_check                   71      42     -29
> >>   hvm_enable                                   449     419     -30
> >>   init_guest_cpu_policies                     1247    1213     -34
> >>   paging_domctl                               3357    3318     -39
> >>   __start_xen                                 9456    9416     -40
> >>   arch_sanitise_domain_config                  794     747     -47
> >>   symbols_offsets                            29636   29588     -48
> >>   p2m_set_entry                                305     247     -58
> >>   guest_cpuid                                 1919    1858     -61
> >>   ept_dump_p2m_table                           817     751     -66
> >>   recalculate_cpuid_policy                     874     806     -68
> >>   shadow_domain_init                            71       -     -71
> >>   mmio_order                                    73       -     -73
> >>   hvm_shadow_max_featuremask                    76       -     -76
> >>   hvm_shadow_def_featuremask                    76       -     -76
> >>   dm_op                                       3594    3510     -84
> >>   symbols_sorted_offsets                     58464   58368     -96
> >>   symbols_names                             103425  103213    -212
> >>   Total: Before=3644618, After=3643076, chg -0.04%
> >> ---
> >>  xen/arch/x86/Kconfig               | 2 ++
> >>  xen/arch/x86/hvm/Kconfig           | 3 +++
> >>  xen/arch/x86/hvm/hvm.c             | 8 ++++++++
> >>  xen/arch/x86/include/asm/hvm/hvm.h | 2 +-
> >>  xen/arch/x86/mm/Makefile           | 2 +-
> >>  xen/include/xen/sched.h            | 3 +++
> >>  6 files changed, 18 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> >> index 2ce4747f6e..190f419720 100644
> >> --- a/xen/arch/x86/Kconfig
> >> +++ b/xen/arch/x86/Kconfig
> >> @@ -67,6 +67,7 @@ source "arch/Kconfig"
> >>  config PV
> >>  	def_bool y
> >>  	prompt "PV support"
> >> +	select OPT_HAP
> >>  	help
> >>  	  Interfaces to support PV domains. These require guest kernel support
> >>  	  to run as a PV guest, but don't require any specific hardware support.
> >> @@ -147,6 +148,7 @@ config SHADOW_PAGING
> >>  	bool "Shadow Paging"
> >>  	default !PV_SHIM_EXCLUSIVE
> >>  	depends on PV || HVM
> >> +	select OPT_HAP
> >>  	help
> >>  	  Shadow paging is a software alternative to hardware paging support
> >>  	  (Intel EPT, AMD NPT).
> >> diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
> >> index f32bf5cbb7..310e09847b 100644
> >> --- a/xen/arch/x86/hvm/Kconfig
> >> +++ b/xen/arch/x86/hvm/Kconfig
> >> @@ -92,4 +92,7 @@ config MEM_SHARING
> >>  	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
> >>  	depends on INTEL_VMX
> >>  
> >> +config OPT_HAP
> >> +	bool
> >
> > Can't you define this outside of Kconfig, like:
> >
> > #define HAP_ONLY_BUILD (!IS_ENABLED(CONFIG_PV) && !IS_ENABLED(CONFIG_SHADOW_PAGING))
> 
> Sure.
> 
> >
> > HAP_ONLY_BUILD is likely not the best name.  Maybe CONFIG_HAP_REQUIRED
> > or some such?  (Seeing the usage below)
> 
> Definitely not CONFIG_*, or it'd be an accident about to happen when mistakenly
> used on IS_ENABLED(). HAP_EXCLUSIVE?

I would prefer HAP_REQUIRED, but that's a question of taste.  Both
would be used in the same way.

We have some CONFIG_ defines that won't work with IS_ENABLED()
already, but let's not propagate that further.

> >
> > FWIW, with the current naming I've assume this was supposed to mean
> > "Option HAP" or some such, when is "HAP is Optional".  We usually use
> 
> It was. Originally it had a help message and a default, but I quickly noticed
> that served no purpose. It has that weird polarity so the build would remain
> with new options being additive only.
> 
> In retrospect it can go back to a more natural HAP_EXCLUSIVE that removes
> a bunch of !s in the code.
> 
> > "opt" as a shortcut for "option" in several places on the Xen code
> > base, like "opt_hap_enabled".  I also think using it in the positive
> > for so the variable meaning "required" instead of "optional" makes
> > some of the logic easier to follow below.
> 
> It does, but in Kconfig it's nicer if an option being enabled yields a strictly
> more capable hypervisor, I think. Makes allyesconfig and allnoconfig work as
> intended.

Oh, I see.  Moving it out of Kconfig makes even more sense I think.

> >> +
> >>          return false;
> >>      }
> >>  
> >> +#ifdef CONFIG_OPT_HAP
> >>      if ( !opt_hap_enabled )
> >
> > You could possibly do:
> >
> > #ifdef CONFIG_OPT_HAP
> > /* Xen command-line option to enable HAP */
> > static bool __initdata opt_hap_enabled = true;
> > boolean_param("hap", opt_hap_enabled);
> > #else /* CONFIG_OPT_HAP */
> > # define opt_hap_enabled true
> > #endif /* !CONFIG_OPT_HAP */
> >
> > Above, and avoid the ifdefs here?
> 
> Whatever poison you prefer. It's just ugliness motion.

Yeah, at least this keeps all the ifdefs mostly in the same visual
region.

> >
> >>      {
> >>          fns->caps.hap = false;
> >>          printk("HVM: Hardware Assisted Paging (HAP) detected but disabled\n");
> >>          return false;
> >>      }
> >> +#endif /* CONFIG_OPT_HAP */
> >>  
> >>      return true;
> >>  }
> >> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
> >> index dc609bf4cb..b330d65d6d 100644
> >> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> >> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> >> @@ -703,7 +703,7 @@ static inline bool hvm_is_singlestep_supported(void)
> >>  
> >>  static inline bool hvm_hap_supported(void)
> >>  {
> >> -    return hvm_funcs.caps.hap;
> >> +    return !IS_ENABLED(CONFIG_OPT_HAP) ?: hvm_funcs.caps.hap;
> >
> > return CONFIG_HAP_REQUIRED ?: hvm_funcs.caps.hap;
> >
> > IMO is easier to read (same below for the hap_enabled() early return).
> >
> >>  }
> >>  
> >>  /* returns true if hardware supports alternate p2m's */
> >> diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
> >> index 960f6e8409..64fde82c50 100644
> >> --- a/xen/arch/x86/mm/Makefile
> >> +++ b/xen/arch/x86/mm/Makefile
> >> @@ -1,4 +1,4 @@
> >> -obj-y += shadow/
> >> +obj-$(CONFIG_OPT_HAP) += shadow/
> >
> > I think you can use:
> >
> > obj-$(findstring y,$(CONFIG_PV) $(CONFIG_SHADOW_PAGING)) += ...
> 
> Hmmm. I guess I shouldn't just include it twice, like we do for other .o files.

I see, so use:

obj-$(CONFIG_PV) += shadow/
obj-$(CONFIG_SHADOW_PAGING) += shadow/

Maybe that's simpler really, and it's a pattern we already use
elsewhere.

Thanks, Roger.

Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out

[Alejandro Vallejo]

On Fri Feb 13, 2026 at 7:42 PM CET, Roger Pau Monné wrote:
>> >> diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
>> >> index 960f6e8409..64fde82c50 100644
>> >> --- a/xen/arch/x86/mm/Makefile
>> >> +++ b/xen/arch/x86/mm/Makefile
>> >> @@ -1,4 +1,4 @@
>> >> -obj-y += shadow/
>> >> +obj-$(CONFIG_OPT_HAP) += shadow/
>> >
>> > I think you can use:
>> >
>> > obj-$(findstring y,$(CONFIG_PV) $(CONFIG_SHADOW_PAGING)) += ...
>> 
>> Hmmm. I guess I shouldn't just include it twice, like we do for other .o files.
>
> I see, so use:
>
> obj-$(CONFIG_PV) += shadow/
> obj-$(CONFIG_SHADOW_PAGING) += shadow/
>
> Maybe that's simpler really, and it's a pattern we already use
> elsewhere.

I meant them being folder with makefiles potentially doing things that should
only be done once. I don't know if we dedup tokens somewhere. These makefiles
are rather arcane.

>
> Thanks, Roger.

Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out

[Roger Pau Monné]

On Fri, Feb 13, 2026 at 08:13:09PM +0100, Alejandro Vallejo wrote:
> On Fri Feb 13, 2026 at 7:42 PM CET, Roger Pau Monné wrote:
> >> >> diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
> >> >> index 960f6e8409..64fde82c50 100644
> >> >> --- a/xen/arch/x86/mm/Makefile
> >> >> +++ b/xen/arch/x86/mm/Makefile
> >> >> @@ -1,4 +1,4 @@
> >> >> -obj-y += shadow/
> >> >> +obj-$(CONFIG_OPT_HAP) += shadow/
> >> >
> >> > I think you can use:
> >> >
> >> > obj-$(findstring y,$(CONFIG_PV) $(CONFIG_SHADOW_PAGING)) += ...
> >> 
> >> Hmmm. I guess I shouldn't just include it twice, like we do for other .o files.
> >
> > I see, so use:
> >
> > obj-$(CONFIG_PV) += shadow/
> > obj-$(CONFIG_SHADOW_PAGING) += shadow/
> >
> > Maybe that's simpler really, and it's a pattern we already use
> > elsewhere.
> 
> I meant them being folder with makefiles potentially doing things that should
> only be done once. I don't know if we dedup tokens somewhere. These makefiles
> are rather arcane.

I'm not a Makefile expert, so I might be wrong.  We apply $(sort ...)
in several places to remove duplicates, I would assume, I see:

# Subdirectories we need to descend into
subdir-y := $(sort $(subdir-y) $(patsubst %/,%,$(filter %/, $(obj-y))))

Which should remove any duplicated folders.

I've tried the duplicated folder addition to obj-y and seems to build
fine.

Thanks, Roger.