* [PATCH 0/2] x86: Const-ify hvm_enabled and hap_enabled() when possible
@ 2026-02-13 13:37 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 13:37 ` [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out Alejandro Vallejo
0 siblings, 2 replies; 13+ messages in thread
From: Alejandro Vallejo @ 2026-02-13 13:37 UTC (permalink / raw)
To: xen-devel
Cc: Alejandro Vallejo, Jan Beulich, Andrew Cooper,
Roger Pau Monné, Anthony PERARD, Michal Orzel, Julien Grall,
Stefano Stabellini
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled
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 ` Alejandro Vallejo
2026-02-13 14:26 ` 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
1 sibling, 1 reply; 13+ messages in thread
From: Alejandro Vallejo @ 2026-02-13 13:37 UTC (permalink / raw)
To: xen-devel
Cc: Alejandro Vallejo, Jan Beulich, Andrew Cooper,
Roger Pau Monné
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out
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 13:37 ` Alejandro Vallejo
2026-02-13 15:09 ` Roger Pau Monné
1 sibling, 1 reply; 13+ messages in thread
From: Alejandro Vallejo @ 2026-02-13 13:37 UTC (permalink / raw)
To: xen-devel
Cc: Alejandro Vallejo, Jan Beulich, Andrew Cooper,
Roger Pau Monné, Anthony PERARD, Michal Orzel, Julien Grall,
Stefano Stabellini
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled
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 17:04 ` Alejandro Vallejo
0 siblings, 2 replies; 13+ messages in thread
From: Roger Pau Monné @ 2026-02-13 14:26 UTC (permalink / raw)
To: Alejandro Vallejo; +Cc: xen-devel, Jan Beulich, Andrew Cooper
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out
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
0 siblings, 1 reply; 13+ messages in thread
From: Roger Pau Monné @ 2026-02-13 15:09 UTC (permalink / raw)
To: Alejandro Vallejo
Cc: xen-devel, Jan Beulich, Andrew Cooper, Anthony PERARD,
Michal Orzel, Julien Grall, Stefano Stabellini
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled
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
1 sibling, 1 reply; 13+ messages in thread
From: Andrew Cooper @ 2026-02-13 16:01 UTC (permalink / raw)
To: Roger Pau Monné, Alejandro Vallejo
Cc: Andrew Cooper, xen-devel, Jan Beulich
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled
2026-02-13 16:01 ` Andrew Cooper
@ 2026-02-13 16:33 ` Roger Pau Monné
0 siblings, 0 replies; 13+ messages in thread
From: Roger Pau Monné @ 2026-02-13 16:33 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Alejandro Vallejo, xen-devel, Jan Beulich
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled
2026-02-13 14:26 ` Roger Pau Monné
2026-02-13 16:01 ` Andrew Cooper
@ 2026-02-13 17:04 ` Alejandro Vallejo
2026-02-13 18:30 ` Roger Pau Monné
1 sibling, 1 reply; 13+ messages in thread
From: Alejandro Vallejo @ 2026-02-13 17:04 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel, Jan Beulich, Andrew Cooper
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out
2026-02-13 15:09 ` Roger Pau Monné
@ 2026-02-13 17:30 ` Alejandro Vallejo
2026-02-13 18:42 ` Roger Pau Monné
0 siblings, 1 reply; 13+ messages in thread
From: Alejandro Vallejo @ 2026-02-13 17:30 UTC (permalink / raw)
To: Roger Pau Monné
Cc: xen-devel, Jan Beulich, Andrew Cooper, Anthony PERARD,
Michal Orzel, Julien Grall, Stefano Stabellini
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] x86: Make hvm_enabled a constant unless both PV and HVM are both compiled
2026-02-13 17:04 ` Alejandro Vallejo
@ 2026-02-13 18:30 ` Roger Pau Monné
0 siblings, 0 replies; 13+ messages in thread
From: Roger Pau Monné @ 2026-02-13 18:30 UTC (permalink / raw)
To: Alejandro Vallejo; +Cc: xen-devel, Jan Beulich, Andrew Cooper
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out
2026-02-13 17:30 ` Alejandro Vallejo
@ 2026-02-13 18:42 ` Roger Pau Monné
2026-02-13 19:13 ` Alejandro Vallejo
0 siblings, 1 reply; 13+ messages in thread
From: Roger Pau Monné @ 2026-02-13 18:42 UTC (permalink / raw)
To: Alejandro Vallejo
Cc: xen-devel, Jan Beulich, Andrew Cooper, Anthony PERARD,
Michal Orzel, Julien Grall, Stefano Stabellini
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out
2026-02-13 18:42 ` Roger Pau Monné
@ 2026-02-13 19:13 ` Alejandro Vallejo
2026-02-13 19:54 ` Roger Pau Monné
0 siblings, 1 reply; 13+ messages in thread
From: Alejandro Vallejo @ 2026-02-13 19:13 UTC (permalink / raw)
To: Roger Pau Monné
Cc: xen-devel, Jan Beulich, Andrew Cooper, Anthony PERARD,
Michal Orzel, Julien Grall, Stefano Stabellini
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] x86: Force HAP to be enabled when PV and shadow paging are compiled out
2026-02-13 19:13 ` Alejandro Vallejo
@ 2026-02-13 19:54 ` Roger Pau Monné
0 siblings, 0 replies; 13+ messages in thread
From: Roger Pau Monné @ 2026-02-13 19:54 UTC (permalink / raw)
To: Alejandro Vallejo
Cc: xen-devel, Jan Beulich, Andrew Cooper, Anthony PERARD,
Michal Orzel, Julien Grall, Stefano Stabellini
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2026-02-13 19:54 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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é
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.