[PATCH 0/4] xen: cleanup config files

[PATCH 0/4] xen: cleanup config files

[Juergen Gross]

Do a cleanup of the Xen related Kconfig entries.

Juergen Gross (4):
  x86/xen: Remove redundant config dependency on X86_LOCAL_APIC
  xen: Drop CONFIG_XEN_PVHVM
  xen: Drop CONFIG_XEN_AUTO_XLATE
  x86/xen: Drop CONFIG_XEN_PVHVM_SMP

 arch/x86/include/asm/idtentry.h   |  2 +-
 arch/x86/kernel/cpu/hypervisor.c  |  2 +-
 arch/x86/xen/Kconfig              | 12 ++----------
 arch/x86/xen/Makefile             | 11 +++++------
 arch/x86/xen/time.c               |  2 --
 arch/x86/xen/xen-ops.h            |  4 ----
 drivers/xen/Kconfig               |  6 ------
 drivers/xen/Makefile              |  2 +-
 drivers/xen/events/events_base.c  |  7 -------
 drivers/xen/privcmd.c             |  4 ++--
 drivers/xen/xenbus/xenbus_probe.c |  2 +-
 include/xen/platform_pci.h        |  6 +++---
 include/xen/xen-ops.h             | 22 ----------------------
 13 files changed, 16 insertions(+), 66 deletions(-)

-- 
2.55.0

[PATCH 1/4] x86/xen: Remove redundant config dependency on X86_LOCAL_APIC

[Juergen Gross]

CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 99b06f5c47cd..bb420a4cb75f 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -52,7 +52,7 @@ config XEN_PV_DOM0
 
 config XEN_PVHVM
 	def_bool y
-	depends on XEN && X86_LOCAL_APIC
+	depends on XEN
 
 config XEN_PVHVM_SMP
 	def_bool y
-- 
2.55.0

Re: [PATCH 1/4] x86/xen: Remove redundant config dependency on X86_LOCAL_APIC

[Jan Beulich]

On 05.08.2026 10:21, Juergen Gross wrote:
> CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
> of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

I've been noticing this every once in a while, but it never felt quite important
enough to make a patch, sorry.

Jan

Re: [PATCH 1/4] x86/xen: Remove redundant config dependency on X86_LOCAL_APIC

[Jan Beulich]

On 05.08.2026 10:37, Jan Beulich wrote:
> On 05.08.2026 10:21, Juergen Gross wrote:
>> CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
>> of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Hmm, looking at patch 2 I wonder: Isn't it XEN's dependency which wants
dropping? XEN_PV shouldn't require X86_LOCAL_APIC, should it?

Jan

Re: [PATCH 1/4] x86/xen: Remove redundant config dependency on X86_LOCAL_APIC

[Andrew Cooper]

On 05/08/2026 9:40 am, Jan Beulich wrote:
> On 05.08.2026 10:37, Jan Beulich wrote:
>> On 05.08.2026 10:21, Juergen Gross wrote:
>>> CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
>>> of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> Hmm, looking at patch 2 I wonder: Isn't it XEN's dependency which wants
> dropping? XEN_PV shouldn't require X86_LOCAL_APIC, should it?

In Linux terms, XEN_PV does need X86_LOCAL_APIC.

While the PV guest doesn't have an APIC directly, other areas (parsing
the ACPI tables, configuring device interrupts) require Linux to think
it's on a normal APIC-like system.

~Andrew

Re: [PATCH 1/4] x86/xen: Remove redundant config dependency on X86_LOCAL_APIC

[Stefano Stabellini]

On Wed, 5 Aug 2026, Juergen Gross wrote:
> CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
> of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  arch/x86/xen/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 99b06f5c47cd..bb420a4cb75f 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -52,7 +52,7 @@ config XEN_PV_DOM0
>  
>  config XEN_PVHVM
>  	def_bool y
> -	depends on XEN && X86_LOCAL_APIC
> +	depends on XEN
>  
>  config XEN_PVHVM_SMP
>  	def_bool y
> -- 
> 2.55.0
> 
> 

[PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM

[Juergen Gross]

On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.

In Xen specific x86 code it can be just dropped, in non-Xen specific
x86 code it can be replaced with CONFIG_XEN.

In architecture independent code it is used only where CONFIG_XEN is
defined, so it can be replaced with CONFIG_X86 there.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/idtentry.h   |  2 +-
 arch/x86/kernel/cpu/hypervisor.c  |  2 +-
 arch/x86/xen/Kconfig              | 10 +++-------
 arch/x86/xen/Makefile             |  9 ++++-----
 arch/x86/xen/time.c               |  2 --
 arch/x86/xen/xen-ops.h            |  4 ----
 drivers/xen/Kconfig               |  2 +-
 drivers/xen/events/events_base.c  |  7 -------
 drivers/xen/xenbus/xenbus_probe.c |  2 +-
 include/xen/platform_pci.h        |  6 +++---
 10 files changed, 14 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index 20f548702404..f400cfac69a6 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -745,7 +745,7 @@ DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR,		sysvec_hyperv_stimer0);
 DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_acrn_hv_callback);
 #endif
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_XEN
 DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_xen_hvm_callback);
 #endif
 
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index f3e9219845e8..73428afca796 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -31,7 +31,7 @@ static const __initconst struct hypervisor_x86 * const hypervisors[] =
 #ifdef CONFIG_XEN_PV
 	&x86_hyper_xen_pv,
 #endif
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_XEN
 	&x86_hyper_xen_hvm,
 #endif
 	&x86_hyper_vmware,
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index bb420a4cb75f..9e5bb51eecf4 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,24 +50,20 @@ config XEN_PV_DOM0
 	def_bool y
 	depends on XEN_PV && XEN_DOM0
 
-config XEN_PVHVM
-	def_bool y
-	depends on XEN
-
 config XEN_PVHVM_SMP
 	def_bool y
-	depends on XEN_PVHVM && SMP
+	depends on XEN && SMP
 
 config XEN_PVHVM_GUEST
 	bool "Xen PVHVM guest support"
 	default y
-	depends on XEN_PVHVM && PCI
+	depends on XEN && PCI
 	help
 	  Support running as a Xen PVHVM guest.
 
 config XEN_PVH
 	bool "Xen PVH guest support"
-	depends on XEN && XEN_PVHVM && ACPI
+	depends on XEN && ACPI
 	select PVH
 	help
 	  Support for running as a Xen PVH guest.
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 717264ae269b..32d651aa9bc2 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -16,11 +16,10 @@ obj-y				+= mmu.o
 obj-y				+= time.o
 obj-y				+= grant-table.o
 obj-y				+= suspend.o
-
-obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o
-obj-$(CONFIG_XEN_PVHVM)		+= mmu_hvm.o
-obj-$(CONFIG_XEN_PVHVM)		+= suspend_hvm.o
-obj-$(CONFIG_XEN_PVHVM)		+= platform-pci-unplug.o
+obj-y				+= enlighten_hvm.o
+obj-y				+= mmu_hvm.o
+obj-y				+= suspend_hvm.o
+obj-y				+= platform-pci-unplug.o
 
 obj-$(CONFIG_XEN_PV)		+= setup.o
 obj-$(CONFIG_XEN_PV)		+= apic.o
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index d62c14334b35..5c7822254a01 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -586,7 +586,6 @@ void __init xen_init_time_ops(void)
 		x86_platform.set_wallclock = xen_set_wallclock;
 }
 
-#ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_setup_cpu_clockevents(void)
 {
 	int cpu = smp_processor_id();
@@ -643,7 +642,6 @@ void __init xen_hvm_init_time_ops(void)
 
 	hvm_time_initialized = true;
 }
-#endif
 
 /* Kernel parameter to specify Xen timer slop */
 static int __init parse_xen_timer_slop(char *ptr)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index dc265bdda24d..47eebbb3684a 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -236,11 +236,7 @@ void xen_pin_vcpu(int cpu);
 
 void xen_emergency_restart(void);
 
-#ifdef CONFIG_XEN_PVHVM
 void xen_hvm_post_suspend(int suspend_cancelled);
-#else
-static inline void xen_hvm_post_suspend(int suspend_cancelled) {}
-#endif
 
 /*
  * The maximum amount of extra memory compared to the base size.  The
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index f9a35ed266ec..cfb517cd77dc 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -311,7 +311,7 @@ config XEN_EFI
 
 config XEN_AUTO_XLATE
 	def_bool y
-	depends on ARM || ARM64 || XEN_PVHVM
+	depends on ARM || ARM64 || X86
 	help
 	  Support for auto-translated physmap guests.
 
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 6ea945508a89..fd16d652c81f 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2180,7 +2180,6 @@ static struct irq_chip xen_percpu_chip __read_mostly = {
 };
 
 #ifdef CONFIG_X86
-#ifdef CONFIG_XEN_PVHVM
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -2242,12 +2241,6 @@ static __init void xen_alloc_callback_vector(void)
 	pr_info("Xen HVM callback vector for event delivery is enabled\n");
 	sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_xen_hvm_callback);
 }
-#else
-void xen_setup_callback_vector(void) {}
-static inline void xen_init_setup_upcall_vector(void) {}
-int xen_set_upcall_vector(unsigned int cpu) {}
-static inline void xen_alloc_callback_vector(void) {}
-#endif /* CONFIG_XEN_PVHVM */
 #endif /* CONFIG_X86 */
 
 bool xen_fifo_events = true;
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index fafb2b84fa5c..082b8c1fee8e 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -831,7 +831,7 @@ static void xenbus_probe(void)
  */
 static bool xs_hvm_defer_init_for_callback(void)
 {
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 	return xen_store_domain_type == XS_HVM &&
 		!xen_have_vector_callback;
 #else
diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
index e51e7cb71a85..267040c1f504 100644
--- a/include/xen/platform_pci.h
+++ b/include/xen/platform_pci.h
@@ -30,7 +30,7 @@
 static inline int xen_must_unplug_nics(void) {
 #if (defined(CONFIG_XEN_NETDEV_FRONTEND) || \
 		defined(CONFIG_XEN_NETDEV_FRONTEND_MODULE)) && \
-		defined(CONFIG_XEN_PVHVM)
+		defined(CONFIG_X86)
         return 1;
 #else
         return 0;
@@ -40,14 +40,14 @@ static inline int xen_must_unplug_nics(void) {
 static inline int xen_must_unplug_disks(void) {
 #if (defined(CONFIG_XEN_BLKDEV_FRONTEND) || \
 		defined(CONFIG_XEN_BLKDEV_FRONTEND_MODULE)) && \
-		defined(CONFIG_XEN_PVHVM)
+		defined(CONFIG_X86)
         return 1;
 #else
         return 0;
 #endif
 }
 
-#if defined(CONFIG_XEN_PVHVM)
+#if defined(CONFIG_X86)
 extern bool xen_has_pv_devices(void);
 extern bool xen_has_pv_disk_devices(void);
 extern bool xen_has_pv_nic_devices(void);
-- 
2.55.0

Re: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM

[Andrew Cooper]

On 05/08/2026 9:21 am, Juergen Gross wrote:
> On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.
>
> In Xen specific x86 code it can be just dropped, in non-Xen specific
> x86 code it can be replaced with CONFIG_XEN.
>
> In architecture independent code it is used only where CONFIG_XEN is
> defined, so it can be replaced with CONFIG_X86 there.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
>
> diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
> index 20f548702404..f400cfac69a6 100644
> --- a/arch/x86/include/asm/idtentry.h
> +++ b/arch/x86/include/asm/idtentry.h
> @@ -745,7 +745,7 @@ DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR,		sysvec_hyperv_stimer0);
>  DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_acrn_hv_callback);
>  #endif
>  
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_XEN
>  DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_xen_hvm_callback);
>  #endif

I'm very happy to see a reduction in the number of Kconfig symbols for
Xen (there are definitely too many), but this looks wonky.

Or are you saying that there really is no way to build a Xen PV guest
excluding the HVM-only bits?

~Andrew

Re: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 1481 bytes --]

On 05.08.26 10:28, Andrew Cooper wrote:
> On 05/08/2026 9:21 am, Juergen Gross wrote:
>> On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.
>>
>> In Xen specific x86 code it can be just dropped, in non-Xen specific
>> x86 code it can be replaced with CONFIG_XEN.
>>
>> In architecture independent code it is used only where CONFIG_XEN is
>> defined, so it can be replaced with CONFIG_X86 there.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>
>> diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
>> index 20f548702404..f400cfac69a6 100644
>> --- a/arch/x86/include/asm/idtentry.h
>> +++ b/arch/x86/include/asm/idtentry.h
>> @@ -745,7 +745,7 @@ DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR,		sysvec_hyperv_stimer0);
>>   DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_acrn_hv_callback);
>>   #endif
>>   
>> -#ifdef CONFIG_XEN_PVHVM
>> +#ifdef CONFIG_XEN
>>   DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_xen_hvm_callback);
>>   #endif
> 
> I'm very happy to see a reduction in the number of Kconfig symbols for
> Xen (there are definitely too many), but this looks wonky.
> 
> Or are you saying that there really is no way to build a Xen PV guest
> excluding the HVM-only bits?

Seems so, yes.

This has been like this for at least several years now.

What you can do is to configure the kernel to exclude the Xen platform PCI
device (CONFIG_XEN_PVHVM_GUEST=n).


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM

[Jason Andryuk]

On 2026-08-05 04:36, Juergen Gross wrote:
> On 05.08.26 10:28, Andrew Cooper wrote:
>> On 05/08/2026 9:21 am, Juergen Gross wrote:
>>> On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.
>>>
>>> In Xen specific x86 code it can be just dropped, in non-Xen specific
>>> x86 code it can be replaced with CONFIG_XEN.
>>>
>>> In architecture independent code it is used only where CONFIG_XEN is
>>> defined, so it can be replaced with CONFIG_X86 there.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/ 
>>> idtentry.h
>>> index 20f548702404..f400cfac69a6 100644
>>> --- a/arch/x86/include/asm/idtentry.h
>>> +++ b/arch/x86/include/asm/idtentry.h
>>> @@ -745,7 +745,7 @@ 
>>> DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR,        
>>> sysvec_hyperv_stimer0);
>>>   DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,    
>>> sysvec_acrn_hv_callback);
>>>   #endif
>>> -#ifdef CONFIG_XEN_PVHVM
>>> +#ifdef CONFIG_XEN
>>>   DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,    
>>> sysvec_xen_hvm_callback);
>>>   #endif
>>
>> I'm very happy to see a reduction in the number of Kconfig symbols for
>> Xen (there are definitely too many), but this looks wonky.
>>
>> Or are you saying that there really is no way to build a Xen PV guest
>> excluding the HVM-only bits?
> 
> Seems so, yes.
> 
> This has been like this for at least several years now.
> 
> What you can do is to configure the kernel to exclude the Xen platform PCI
> device (CONFIG_XEN_PVHVM_GUEST=n).
I think I caused this inadvertently in 34aff14580d1 ("xen: Remove Xen 
PVH/PVHVM dependency on PCI")

CONFIG_XEN_PVHVM should just be bool, and then XEN_PVH & XEN_PVHVM_GUEST 
can select it.  Then it can be disabled for a PV only build.

I'll send it out, so you can evaluate it.

Regards,
Jason

Re: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM

[Stefano Stabellini]

On Wed, 5 Aug 2026, Juergen Gross wrote:
> On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.
> 
> In Xen specific x86 code it can be just dropped, in non-Xen specific
> x86 code it can be replaced with CONFIG_XEN.
> 
> In architecture independent code it is used only where CONFIG_XEN is
> defined, so it can be replaced with CONFIG_X86 there.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

While I think there is value in compiling a tiny PV-only kernel (in
fact I even have a real-world use case for it) the code addition is
minimal and also considering your reply to Andrew:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  arch/x86/include/asm/idtentry.h   |  2 +-
>  arch/x86/kernel/cpu/hypervisor.c  |  2 +-
>  arch/x86/xen/Kconfig              | 10 +++-------
>  arch/x86/xen/Makefile             |  9 ++++-----
>  arch/x86/xen/time.c               |  2 --
>  arch/x86/xen/xen-ops.h            |  4 ----
>  drivers/xen/Kconfig               |  2 +-
>  drivers/xen/events/events_base.c  |  7 -------
>  drivers/xen/xenbus/xenbus_probe.c |  2 +-
>  include/xen/platform_pci.h        |  6 +++---
>  10 files changed, 14 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
> index 20f548702404..f400cfac69a6 100644
> --- a/arch/x86/include/asm/idtentry.h
> +++ b/arch/x86/include/asm/idtentry.h
> @@ -745,7 +745,7 @@ DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR,		sysvec_hyperv_stimer0);
>  DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_acrn_hv_callback);
>  #endif
>  
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_XEN
>  DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_xen_hvm_callback);
>  #endif
>  
> diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
> index f3e9219845e8..73428afca796 100644
> --- a/arch/x86/kernel/cpu/hypervisor.c
> +++ b/arch/x86/kernel/cpu/hypervisor.c
> @@ -31,7 +31,7 @@ static const __initconst struct hypervisor_x86 * const hypervisors[] =
>  #ifdef CONFIG_XEN_PV
>  	&x86_hyper_xen_pv,
>  #endif
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_XEN
>  	&x86_hyper_xen_hvm,
>  #endif
>  	&x86_hyper_vmware,
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index bb420a4cb75f..9e5bb51eecf4 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,24 +50,20 @@ config XEN_PV_DOM0
>  	def_bool y
>  	depends on XEN_PV && XEN_DOM0
>  
> -config XEN_PVHVM
> -	def_bool y
> -	depends on XEN
> -
>  config XEN_PVHVM_SMP
>  	def_bool y
> -	depends on XEN_PVHVM && SMP
> +	depends on XEN && SMP
>  
>  config XEN_PVHVM_GUEST
>  	bool "Xen PVHVM guest support"
>  	default y
> -	depends on XEN_PVHVM && PCI
> +	depends on XEN && PCI
>  	help
>  	  Support running as a Xen PVHVM guest.
>  
>  config XEN_PVH
>  	bool "Xen PVH guest support"
> -	depends on XEN && XEN_PVHVM && ACPI
> +	depends on XEN && ACPI
>  	select PVH
>  	help
>  	  Support for running as a Xen PVH guest.
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 717264ae269b..32d651aa9bc2 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -16,11 +16,10 @@ obj-y				+= mmu.o
>  obj-y				+= time.o
>  obj-y				+= grant-table.o
>  obj-y				+= suspend.o
> -
> -obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o
> -obj-$(CONFIG_XEN_PVHVM)		+= mmu_hvm.o
> -obj-$(CONFIG_XEN_PVHVM)		+= suspend_hvm.o
> -obj-$(CONFIG_XEN_PVHVM)		+= platform-pci-unplug.o
> +obj-y				+= enlighten_hvm.o
> +obj-y				+= mmu_hvm.o
> +obj-y				+= suspend_hvm.o
> +obj-y				+= platform-pci-unplug.o
>  
>  obj-$(CONFIG_XEN_PV)		+= setup.o
>  obj-$(CONFIG_XEN_PV)		+= apic.o
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index d62c14334b35..5c7822254a01 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -586,7 +586,6 @@ void __init xen_init_time_ops(void)
>  		x86_platform.set_wallclock = xen_set_wallclock;
>  }
>  
> -#ifdef CONFIG_XEN_PVHVM
>  static void xen_hvm_setup_cpu_clockevents(void)
>  {
>  	int cpu = smp_processor_id();
> @@ -643,7 +642,6 @@ void __init xen_hvm_init_time_ops(void)
>  
>  	hvm_time_initialized = true;
>  }
> -#endif
>  
>  /* Kernel parameter to specify Xen timer slop */
>  static int __init parse_xen_timer_slop(char *ptr)
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index dc265bdda24d..47eebbb3684a 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -236,11 +236,7 @@ void xen_pin_vcpu(int cpu);
>  
>  void xen_emergency_restart(void);
>  
> -#ifdef CONFIG_XEN_PVHVM
>  void xen_hvm_post_suspend(int suspend_cancelled);
> -#else
> -static inline void xen_hvm_post_suspend(int suspend_cancelled) {}
> -#endif
>  
>  /*
>   * The maximum amount of extra memory compared to the base size.  The
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index f9a35ed266ec..cfb517cd77dc 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -311,7 +311,7 @@ config XEN_EFI
>  
>  config XEN_AUTO_XLATE
>  	def_bool y
> -	depends on ARM || ARM64 || XEN_PVHVM
> +	depends on ARM || ARM64 || X86
>  	help
>  	  Support for auto-translated physmap guests.
>  
> diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
> index 6ea945508a89..fd16d652c81f 100644
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -2180,7 +2180,6 @@ static struct irq_chip xen_percpu_chip __read_mostly = {
>  };
>  
>  #ifdef CONFIG_X86
> -#ifdef CONFIG_XEN_PVHVM
>  /* Vector callbacks are better than PCI interrupts to receive event
>   * channel notifications because we can receive vector callbacks on any
>   * vcpu and we don't need PCI support or APIC interactions. */
> @@ -2242,12 +2241,6 @@ static __init void xen_alloc_callback_vector(void)
>  	pr_info("Xen HVM callback vector for event delivery is enabled\n");
>  	sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_xen_hvm_callback);
>  }
> -#else
> -void xen_setup_callback_vector(void) {}
> -static inline void xen_init_setup_upcall_vector(void) {}
> -int xen_set_upcall_vector(unsigned int cpu) {}
> -static inline void xen_alloc_callback_vector(void) {}
> -#endif /* CONFIG_XEN_PVHVM */
>  #endif /* CONFIG_X86 */
>  
>  bool xen_fifo_events = true;
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index fafb2b84fa5c..082b8c1fee8e 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -831,7 +831,7 @@ static void xenbus_probe(void)
>   */
>  static bool xs_hvm_defer_init_for_callback(void)
>  {
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_X86
>  	return xen_store_domain_type == XS_HVM &&
>  		!xen_have_vector_callback;
>  #else
> diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
> index e51e7cb71a85..267040c1f504 100644
> --- a/include/xen/platform_pci.h
> +++ b/include/xen/platform_pci.h
> @@ -30,7 +30,7 @@
>  static inline int xen_must_unplug_nics(void) {
>  #if (defined(CONFIG_XEN_NETDEV_FRONTEND) || \
>  		defined(CONFIG_XEN_NETDEV_FRONTEND_MODULE)) && \
> -		defined(CONFIG_XEN_PVHVM)
> +		defined(CONFIG_X86)
>          return 1;
>  #else
>          return 0;
> @@ -40,14 +40,14 @@ static inline int xen_must_unplug_nics(void) {
>  static inline int xen_must_unplug_disks(void) {
>  #if (defined(CONFIG_XEN_BLKDEV_FRONTEND) || \
>  		defined(CONFIG_XEN_BLKDEV_FRONTEND_MODULE)) && \
> -		defined(CONFIG_XEN_PVHVM)
> +		defined(CONFIG_X86)
>          return 1;
>  #else
>          return 0;
>  #endif
>  }
>  
> -#if defined(CONFIG_XEN_PVHVM)
> +#if defined(CONFIG_X86)
>  extern bool xen_has_pv_devices(void);
>  extern bool xen_has_pv_disk_devices(void);
>  extern bool xen_has_pv_nic_devices(void);
> -- 
> 2.55.0
> 

[PATCH 3/4] xen: Drop CONFIG_XEN_AUTO_XLATE

[Juergen Gross]

CONFIG_XEN_AUTO_XLATE is referenced only in code built with CONFIG_XEN
enabled. As it is enabled for all architectures supporting Xen, it can
be just dropped.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 drivers/xen/Kconfig   |  6 ------
 drivers/xen/Makefile  |  2 +-
 drivers/xen/privcmd.c |  4 ++--
 include/xen/xen-ops.h | 22 ----------------------
 4 files changed, 3 insertions(+), 31 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index cfb517cd77dc..32e35a8580ee 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -309,12 +309,6 @@ config XEN_EFI
 	def_bool y
 	depends on (ARM || ARM64 || X86_64) && EFI
 
-config XEN_AUTO_XLATE
-	def_bool y
-	depends on ARM || ARM64 || X86
-	help
-	  Support for auto-translated physmap guests.
-
 config XEN_ACPI
 	def_bool y
 	depends on X86 && ACPI
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index c0503f1c7d5b..6ce2e2a52d47 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 obj-y	+= grant-table.o features.o balloon.o manage.o time.o
 obj-y	+= mem-reservation.o
+obj-y	+= xlate_mmu.o
 obj-y	+= events/
 obj-y	+= xenbus/
 
@@ -29,7 +30,6 @@ obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
 obj-$(CONFIG_XEN_EFI)			+= efi.o
 obj-$(CONFIG_XEN_SCSI_BACKEND)		+= xen-scsiback.o
-obj-$(CONFIG_XEN_AUTO_XLATE)		+= xlate_mmu.o
 obj-$(CONFIG_XEN_PVCALLS_BACKEND)	+= pvcalls-back.o
 obj-$(CONFIG_XEN_PVCALLS_FRONTEND)	+= pvcalls-front.o
 xen-evtchn-y				:= evtchn.o
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 725a49a0eee7..7cfc28f1bb86 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -794,7 +794,7 @@ static long privcmd_ioctl_mmap_resource(struct file *file,
 		goto out;
 	}
 
-	if (IS_ENABLED(CONFIG_XEN_AUTO_XLATE) && !xen_pv_domain()) {
+	if (!xen_pv_domain()) {
 		unsigned int nr = DIV_ROUND_UP(kdata.num, XEN_PFN_PER_PAGE);
 		struct page **pages;
 		unsigned int i;
@@ -825,7 +825,7 @@ static long privcmd_ioctl_mmap_resource(struct file *file,
 	if (rc)
 		goto out;
 
-	if (IS_ENABLED(CONFIG_XEN_AUTO_XLATE) && !xen_pv_domain()) {
+	if (!xen_pv_domain()) {
 		rc = xen_remap_vma_range(vma, kdata.addr, kdata.num << PAGE_SHIFT);
 	} else {
 		unsigned int domid =
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 496e6013c689..15e0c3f4b7bb 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -59,7 +59,6 @@ static inline int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
 
 struct vm_area_struct;
 
-#ifdef CONFIG_XEN_AUTO_XLATE
 int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
 			      unsigned long addr,
 			      xen_pfn_t *gfn, int nr,
@@ -68,27 +67,6 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
 			      struct page **pages);
 int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
 			      int nr, struct page **pages);
-#else
-/*
- * These two functions are called from arch/x86/xen/mmu.c and so stubs
- * are needed for a configuration not specifying CONFIG_XEN_AUTO_XLATE.
- */
-static inline int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
-					    unsigned long addr,
-					    xen_pfn_t *gfn, int nr,
-					    int *err_ptr, pgprot_t prot,
-					    unsigned int domid,
-					    struct page **pages)
-{
-	return -EOPNOTSUPP;
-}
-
-static inline int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
-					    int nr, struct page **pages)
-{
-	return -EOPNOTSUPP;
-}
-#endif
 
 int xen_remap_vma_range(struct vm_area_struct *vma, unsigned long addr,
 			unsigned long len);
-- 
2.55.0

Re: [PATCH 3/4] xen: Drop CONFIG_XEN_AUTO_XLATE

[Jan Beulich]

On 05.08.2026 10:21, Juergen Gross wrote:
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -309,12 +309,6 @@ config XEN_EFI
>  	def_bool y
>  	depends on (ARM || ARM64 || X86_64) && EFI
>  
> -config XEN_AUTO_XLATE
> -	def_bool y
> -	depends on ARM || ARM64 || X86

Yet is/was X86 correct here? Shouldn't that exclude PV-only configs?

Jan

Re: [PATCH 3/4] xen: Drop CONFIG_XEN_AUTO_XLATE

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 458 bytes --]

On 05.08.26 10:42, Jan Beulich wrote:
> On 05.08.2026 10:21, Juergen Gross wrote:
>> --- a/drivers/xen/Kconfig
>> +++ b/drivers/xen/Kconfig
>> @@ -309,12 +309,6 @@ config XEN_EFI
>>   	def_bool y
>>   	depends on (ARM || ARM64 || X86_64) && EFI
>>   
>> -config XEN_AUTO_XLATE
>> -	def_bool y
>> -	depends on ARM || ARM64 || X86
> 
> Yet is/was X86 correct here? Shouldn't that exclude PV-only configs?

Again, those don't exist.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 3/4] xen: Drop CONFIG_XEN_AUTO_XLATE

[Stefano Stabellini]

On Wed, 5 Aug 2026, Juergen Gross wrote:
> CONFIG_XEN_AUTO_XLATE is referenced only in code built with CONFIG_XEN
> enabled. As it is enabled for all architectures supporting Xen, it can
> be just dropped.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

> ---
>  drivers/xen/Kconfig   |  6 ------
>  drivers/xen/Makefile  |  2 +-
>  drivers/xen/privcmd.c |  4 ++--
>  include/xen/xen-ops.h | 22 ----------------------
>  4 files changed, 3 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index cfb517cd77dc..32e35a8580ee 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -309,12 +309,6 @@ config XEN_EFI
>  	def_bool y
>  	depends on (ARM || ARM64 || X86_64) && EFI
>  
> -config XEN_AUTO_XLATE
> -	def_bool y
> -	depends on ARM || ARM64 || X86
> -	help
> -	  Support for auto-translated physmap guests.
> -
>  config XEN_ACPI
>  	def_bool y
>  	depends on X86 && ACPI
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index c0503f1c7d5b..6ce2e2a52d47 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -2,6 +2,7 @@
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  obj-y	+= grant-table.o features.o balloon.o manage.o time.o
>  obj-y	+= mem-reservation.o
> +obj-y	+= xlate_mmu.o
>  obj-y	+= events/
>  obj-y	+= xenbus/
>  
> @@ -29,7 +30,6 @@ obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
>  obj-$(CONFIG_XEN_EFI)			+= efi.o
>  obj-$(CONFIG_XEN_SCSI_BACKEND)		+= xen-scsiback.o
> -obj-$(CONFIG_XEN_AUTO_XLATE)		+= xlate_mmu.o
>  obj-$(CONFIG_XEN_PVCALLS_BACKEND)	+= pvcalls-back.o
>  obj-$(CONFIG_XEN_PVCALLS_FRONTEND)	+= pvcalls-front.o
>  xen-evtchn-y				:= evtchn.o
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 725a49a0eee7..7cfc28f1bb86 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -794,7 +794,7 @@ static long privcmd_ioctl_mmap_resource(struct file *file,
>  		goto out;
>  	}
>  
> -	if (IS_ENABLED(CONFIG_XEN_AUTO_XLATE) && !xen_pv_domain()) {
> +	if (!xen_pv_domain()) {
>  		unsigned int nr = DIV_ROUND_UP(kdata.num, XEN_PFN_PER_PAGE);
>  		struct page **pages;
>  		unsigned int i;
> @@ -825,7 +825,7 @@ static long privcmd_ioctl_mmap_resource(struct file *file,
>  	if (rc)
>  		goto out;
>  
> -	if (IS_ENABLED(CONFIG_XEN_AUTO_XLATE) && !xen_pv_domain()) {
> +	if (!xen_pv_domain()) {
>  		rc = xen_remap_vma_range(vma, kdata.addr, kdata.num << PAGE_SHIFT);
>  	} else {
>  		unsigned int domid =
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 496e6013c689..15e0c3f4b7bb 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -59,7 +59,6 @@ static inline int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
>  
>  struct vm_area_struct;
>  
> -#ifdef CONFIG_XEN_AUTO_XLATE
>  int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>  			      unsigned long addr,
>  			      xen_pfn_t *gfn, int nr,
> @@ -68,27 +67,6 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>  			      struct page **pages);
>  int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
>  			      int nr, struct page **pages);
> -#else
> -/*
> - * These two functions are called from arch/x86/xen/mmu.c and so stubs
> - * are needed for a configuration not specifying CONFIG_XEN_AUTO_XLATE.
> - */
> -static inline int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> -					    unsigned long addr,
> -					    xen_pfn_t *gfn, int nr,
> -					    int *err_ptr, pgprot_t prot,
> -					    unsigned int domid,
> -					    struct page **pages)
> -{
> -	return -EOPNOTSUPP;
> -}
> -
> -static inline int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
> -					    int nr, struct page **pages)
> -{
> -	return -EOPNOTSUPP;
> -}
> -#endif
>  
>  int xen_remap_vma_range(struct vm_area_struct *vma, unsigned long addr,
>  			unsigned long len);
> -- 
> 2.55.0
> 

[PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP

[Juergen Gross]

CONFIG_XEN_PVHVM_SMP is referenced only on x86 in Xen specific code,
so it can be replaced with CONFIG_SMP.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/Kconfig  | 4 ----
 arch/x86/xen/Makefile | 2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 9e5bb51eecf4..609e79942fcb 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,10 +50,6 @@ config XEN_PV_DOM0
 	def_bool y
 	depends on XEN_PV && XEN_DOM0
 
-config XEN_PVHVM_SMP
-	def_bool y
-	depends on XEN && SMP
-
 config XEN_PVHVM_GUEST
 	bool "Xen PVHVM guest support"
 	default y
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 32d651aa9bc2..9c7e9ffffb85 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
 obj-$(CONFIG_EVENT_TRACING)	+= trace.o
 
 obj-$(CONFIG_SMP)		+= smp.o
+obj-$(CONFIG_SMP)		+= smp_hvm.o
 obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
-obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
 
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 
-- 
2.55.0

Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP

[Jan Beulich]

On 05.08.2026 10:21, Juergen Gross wrote:
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>  obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>  
>  obj-$(CONFIG_SMP)		+= smp.o
> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>  obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o

Similar issue here - in a PV-only config smp_hvm.o doesn't want / shouldn't
need building.

Jan

Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 1249 bytes --]

On 05.08.26 10:44, Jan Beulich wrote:
> On 05.08.2026 10:21, Juergen Gross wrote:
>> --- a/arch/x86/xen/Makefile
>> +++ b/arch/x86/xen/Makefile
>> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>>   obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>>   
>>   obj-$(CONFIG_SMP)		+= smp.o
>> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>>   obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
>> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
> 
> Similar issue here - in a PV-only config smp_hvm.o doesn't want / shouldn't
> need building.

Note that I didn't change any functionality.

I agree that it seems a little bit strange, but in the end I believe
the current status is okay-ish. PV-only hasn't been something in upstream
Linux since Xen support was added, as PV was always meant to be an
alternative to bare metal support via paravirt patching. It might have
been possible to build a kernel not really functional on bare metal, but
this was more like the ability to build a x86 kernel not working on any
existing machine.

IMO the Xen kernel config options should allow for adding Xen-specific
features, but minimum Xen support should always have basic HVM support,
which includes the Xen specific performance enhancements.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP

[Jan Beulich]

On 05.08.2026 10:55, Juergen Gross wrote:
> On 05.08.26 10:44, Jan Beulich wrote:
>> On 05.08.2026 10:21, Juergen Gross wrote:
>>> --- a/arch/x86/xen/Makefile
>>> +++ b/arch/x86/xen/Makefile
>>> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>>>   obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>>>   
>>>   obj-$(CONFIG_SMP)		+= smp.o
>>> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>>>   obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
>>> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
>>
>> Similar issue here - in a PV-only config smp_hvm.o doesn't want / shouldn't
>> need building.
> 
> Note that I didn't change any functionality.
> 
> I agree that it seems a little bit strange, but in the end I believe
> the current status is okay-ish. PV-only hasn't been something in upstream
> Linux since Xen support was added, as PV was always meant to be an
> alternative to bare metal support via paravirt patching. It might have
> been possible to build a kernel not really functional on bare metal, but
> this was more like the ability to build a x86 kernel not working on any
> existing machine.
> 
> IMO the Xen kernel config options should allow for adding Xen-specific
> features, but minimum Xen support should always have basic HVM support,
> which includes the Xen specific performance enhancements.

I fear I don't understand this. If I want a kernel just to run as PV Dom0,
why would it need to carry anything HVM-ish? That is (or should be)
entirely unrelated to being able to also run this same kernel on baremetal
then.

Jan

Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 2485 bytes --]

On 05.08.26 11:04, Jan Beulich wrote:
> On 05.08.2026 10:55, Juergen Gross wrote:
>> On 05.08.26 10:44, Jan Beulich wrote:
>>> On 05.08.2026 10:21, Juergen Gross wrote:
>>>> --- a/arch/x86/xen/Makefile
>>>> +++ b/arch/x86/xen/Makefile
>>>> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>>>>    obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>>>>    
>>>>    obj-$(CONFIG_SMP)		+= smp.o
>>>> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>>>>    obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
>>>> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
>>>
>>> Similar issue here - in a PV-only config smp_hvm.o doesn't want / shouldn't
>>> need building.
>>
>> Note that I didn't change any functionality.
>>
>> I agree that it seems a little bit strange, but in the end I believe
>> the current status is okay-ish. PV-only hasn't been something in upstream
>> Linux since Xen support was added, as PV was always meant to be an
>> alternative to bare metal support via paravirt patching. It might have
>> been possible to build a kernel not really functional on bare metal, but
>> this was more like the ability to build a x86 kernel not working on any
>> existing machine.
>>
>> IMO the Xen kernel config options should allow for adding Xen-specific
>> features, but minimum Xen support should always have basic HVM support,
>> which includes the Xen specific performance enhancements.
> 
> I fear I don't understand this. If I want a kernel just to run as PV Dom0,
> why would it need to carry anything HVM-ish? That is (or should be)
> entirely unrelated to being able to also run this same kernel on baremetal
> then.

The fact is that Xen PV-mode was always a feature not really liked especially
by x86 maintainers (this is the polite way to phrase it).

Changing something outside of xen-specific parts of the kernel in favor of PV is
nearly always a fight and I'm pretty sure I only get changes in by playing nice
(not changing more than absolutely necessary and cleaning up constantly). I will
certainly not try to push for a "PV-only" kernel while the hope of the x86
maintainers is more "PV will go away some time in future".

The capability to configure the kernel without HVM stuff but with Xen support
is the way it has been since many years now. Nobody has missed a PV-only kernel,
so I conclude there is no need for that. The closest we will get here is a PVH
only kernel, and this is possible by not enabling CONFIG_XEN_PVHVM_GUEST.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP

[Jan Beulich]

On 05.08.2026 11:44, Jürgen Groß wrote:
> On 05.08.26 11:04, Jan Beulich wrote:
>> On 05.08.2026 10:55, Juergen Gross wrote:
>>> On 05.08.26 10:44, Jan Beulich wrote:
>>>> On 05.08.2026 10:21, Juergen Gross wrote:
>>>>> --- a/arch/x86/xen/Makefile
>>>>> +++ b/arch/x86/xen/Makefile
>>>>> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>>>>>    obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>>>>>    
>>>>>    obj-$(CONFIG_SMP)		+= smp.o
>>>>> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>>>>>    obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
>>>>> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
>>>>
>>>> Similar issue here - in a PV-only config smp_hvm.o doesn't want / shouldn't
>>>> need building.
>>>
>>> Note that I didn't change any functionality.
>>>
>>> I agree that it seems a little bit strange, but in the end I believe
>>> the current status is okay-ish. PV-only hasn't been something in upstream
>>> Linux since Xen support was added, as PV was always meant to be an
>>> alternative to bare metal support via paravirt patching. It might have
>>> been possible to build a kernel not really functional on bare metal, but
>>> this was more like the ability to build a x86 kernel not working on any
>>> existing machine.
>>>
>>> IMO the Xen kernel config options should allow for adding Xen-specific
>>> features, but minimum Xen support should always have basic HVM support,
>>> which includes the Xen specific performance enhancements.
>>
>> I fear I don't understand this. If I want a kernel just to run as PV Dom0,
>> why would it need to carry anything HVM-ish? That is (or should be)
>> entirely unrelated to being able to also run this same kernel on baremetal
>> then.
> 
> The fact is that Xen PV-mode was always a feature not really liked especially
> by x86 maintainers (this is the polite way to phrase it).
> 
> Changing something outside of xen-specific parts of the kernel in favor of PV is
> nearly always a fight and I'm pretty sure I only get changes in by playing nice
> (not changing more than absolutely necessary and cleaning up constantly). I will
> certainly not try to push for a "PV-only" kernel while the hope of the x86
> maintainers is more "PV will go away some time in future".
> 
> The capability to configure the kernel without HVM stuff but with Xen support
> is the way it has been since many years now. Nobody has missed a PV-only kernel,
> so I conclude there is no need for that.

Just FTR - I did, even if maybe I never said so explicitly. But as it's just
me ...

Jan

> The closest we will get here is a PVH
> only kernel, and this is possible by not enabling CONFIG_XEN_PVHVM_GUEST.
> 
> 
> Juergen

Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP

[Stefano Stabellini]

On Wed, 5 Aug 2026, Juergen Gross wrote:
> CONFIG_XEN_PVHVM_SMP is referenced only on x86 in Xen specific code,
> so it can be replaced with CONFIG_SMP.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  arch/x86/xen/Kconfig  | 4 ----
>  arch/x86/xen/Makefile | 2 +-
>  2 files changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 9e5bb51eecf4..609e79942fcb 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,10 +50,6 @@ config XEN_PV_DOM0
>  	def_bool y
>  	depends on XEN_PV && XEN_DOM0
>  
> -config XEN_PVHVM_SMP
> -	def_bool y
> -	depends on XEN && SMP
> -
>  config XEN_PVHVM_GUEST
>  	bool "Xen PVHVM guest support"
>  	default y
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 32d651aa9bc2..9c7e9ffffb85 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>  obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>  
>  obj-$(CONFIG_SMP)		+= smp.o
> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>  obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
>  
>  obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
>  
> -- 
> 2.55.0
> 
>