[PATCH 0/2] xen: Fix PV-only build

[PATCH 0/2] xen: Fix PV-only build

[Jason Andryuk]

Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
code needs to be fixed first.

Jason Andryuk (2):
  xen/events: Fix xen_set_upcall_vector stub
  xen/Kconfig: select XEN_PVHVM

 arch/x86/xen/Kconfig             | 8 +++++---
 drivers/xen/events/events_base.c | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.55.0

[PATCH 1/2] xen/events: Fix xen_set_upcall_vector stub

[Jason Andryuk]

Building the xen_set_upcall_vector stub fails with
error: control reaches end of non-void function.

Return -EINVAL, which matches the hypercall's return for a non-HVM
domain.

This is needed to allow disabling CONFIG_XEN_PVHVM.

Fixes: b1c3497e604d ("x86/xen: Add support for HVMOP_set_evtchn_upcall_vector")
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
 drivers/xen/events/events_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 6ea945508a89..3a5ae96e73cc 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2245,7 +2245,7 @@ static __init void xen_alloc_callback_vector(void)
 #else
 void xen_setup_callback_vector(void) {}
 static inline void xen_init_setup_upcall_vector(void) {}
-int xen_set_upcall_vector(unsigned int cpu) {}
+int xen_set_upcall_vector(unsigned int cpu) { return -EINVAL; }
 static inline void xen_alloc_callback_vector(void) {}
 #endif /* CONFIG_XEN_PVHVM */
 #endif /* CONFIG_X86 */
-- 
2.55.0

[PATCH 2/2] xen/Kconfig: select XEN_PVHVM

[Jason Andryuk]

XEN_PVHVM cannot be disabled as it is a hidden variable with def_bool y.
Switch XEN_PVHVM to a plain bool, and make XEN_PVH and XEN_PVHVM_GUEST
select it.  It will be pulled in as needed, and drop the code from
PV-only builds.

Fixes: 34aff14580d1 ("xen: Remove Xen PVH/PVHVM dependency on PCI")
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
 arch/x86/xen/Kconfig | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 99b06f5c47cd..7bdaa28ff232 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -51,7 +51,7 @@ config XEN_PV_DOM0
 	depends on XEN_PV && XEN_DOM0
 
 config XEN_PVHVM
-	def_bool y
+	bool
 	depends on XEN && X86_LOCAL_APIC
 
 config XEN_PVHVM_SMP
@@ -61,13 +61,15 @@ config XEN_PVHVM_SMP
 config XEN_PVHVM_GUEST
 	bool "Xen PVHVM guest support"
 	default y
-	depends on XEN_PVHVM && PCI
+	depends on XEN && PCI
+	select XEN_PVHVM
 	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 XEN_PVHVM
 	select PVH
 	help
 	  Support for running as a Xen PVH guest.
-- 
2.55.0

Re: [PATCH 2/2] xen/Kconfig: select XEN_PVHVM

[Jan Beulich]

On 06.08.2026 03:52, Jason Andryuk wrote:
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -51,7 +51,7 @@ config XEN_PV_DOM0
>  	depends on XEN_PV && XEN_DOM0
>  
>  config XEN_PVHVM
> -	def_bool y
> +	bool
>  	depends on XEN && X86_LOCAL_APIC

Imo "depends on" on prompt-less, default-off options are at best unhelpful
in the common case. (Aiui it can be helpful when "imply" is used instead of
"select".) Hence I think this dependency wants dropping right in this patch,
justified further by ...

> @@ -61,13 +61,15 @@ config XEN_PVHVM_SMP
>  config XEN_PVHVM_GUEST
>  	bool "Xen PVHVM guest support"
>  	default y
> -	depends on XEN_PVHVM && PCI
> +	depends on XEN && PCI
> +	select XEN_PVHVM
>  	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 XEN_PVHVM
>  	select PVH
>  	help
>  	  Support for running as a Xen PVH guest.

... the XEN dependency being in both of the options selecting XEN_PVHVM and,
as per Jürgen's patch, X86_LOCAL_APIC being redundant anyway.

Jan

Re: [PATCH 0/2] xen: Fix PV-only build

[Juergen Gross]

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

On 06.08.26 03:52, Jason Andryuk wrote:
> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
> code needs to be fixed first.
> 
> Jason Andryuk (2):
>    xen/events: Fix xen_set_upcall_vector stub
>    xen/Kconfig: select XEN_PVHVM
> 
>   arch/x86/xen/Kconfig             | 8 +++++---
>   drivers/xen/events/events_base.c | 2 +-
>   2 files changed, 6 insertions(+), 4 deletions(-)
> 

I did a comparison of a kernel built with your patches disabling XEN_PVHVM
and my patches with XEN_PVHVM_GUEST disabled.

The kernel built with my patches is 6 bytes smaller than the one with your
patches.

So I don't see any reason to take your patches, which conflict with mine,
especially as my patches have a negative diffstat on source level, too.


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 0/2] xen: Fix PV-only build

[Jan Beulich]

On 06.08.2026 12:55, Juergen Gross wrote:
> On 06.08.26 03:52, Jason Andryuk wrote:
>> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
>> code needs to be fixed first.
>>
>> Jason Andryuk (2):
>>    xen/events: Fix xen_set_upcall_vector stub
>>    xen/Kconfig: select XEN_PVHVM
>>
>>   arch/x86/xen/Kconfig             | 8 +++++---
>>   drivers/xen/events/events_base.c | 2 +-
>>   2 files changed, 6 insertions(+), 4 deletions(-)
>>
> 
> I did a comparison of a kernel built with your patches disabling XEN_PVHVM
> and my patches with XEN_PVHVM_GUEST disabled.
> 
> The kernel built with my patches is 6 bytes smaller than the one with your
> patches.

Isn't this a sign of something else needing tweaking, somewhere?

> So I don't see any reason to take your patches, which conflict with mine,
> especially as my patches have a negative diffstat on source level, too.

Hmm, Jason's patches look to move things into a more adequate direction,
though. In which case I think a negative diffstat becomes an irrelevant
argument?

Jan

Re: [PATCH 0/2] xen: Fix PV-only build

[Jürgen Groß]

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

On 06.08.26 13:31, Jan Beulich wrote:
> On 06.08.2026 12:55, Juergen Gross wrote:
>> On 06.08.26 03:52, Jason Andryuk wrote:
>>> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
>>> code needs to be fixed first.
>>>
>>> Jason Andryuk (2):
>>>     xen/events: Fix xen_set_upcall_vector stub
>>>     xen/Kconfig: select XEN_PVHVM
>>>
>>>    arch/x86/xen/Kconfig             | 8 +++++---
>>>    drivers/xen/events/events_base.c | 2 +-
>>>    2 files changed, 6 insertions(+), 4 deletions(-)
>>>
>>
>> I did a comparison of a kernel built with your patches disabling XEN_PVHVM
>> and my patches with XEN_PVHVM_GUEST disabled.
>>
>> The kernel built with my patches is 6 bytes smaller than the one with your
>> patches.
> 
> Isn't this a sign of something else needing tweaking, somewhere?

This is a sign that there are probably only very few really HVM specific paths
(in the sense of: explicitly not marked as irrelevant for PV) in the kernel.
Yes, I'm sure you can find some more, but I'm really not sure this is relevant
for more than a handful of users.

>> So I don't see any reason to take your patches, which conflict with mine,
>> especially as my patches have a negative diffstat on source level, too.
> 
> Hmm, Jason's patches look to move things into a more adequate direction,
> though. In which case I think a negative diffstat becomes an irrelevant
> argument?

Depends on what you are looking for.

My take from this is that a PV-only kernel with Jason's patches is not really
adding any value, while my simplification is at least making things simpler
in terms of code volume and number of Xen related config options.

Of course it would be possible to have a smaller PV-only kernel, but as I said
already, there has been no public demand for that in the last years and the
downsides IMHO far outweigh the potential gain.

IMO the "adequate direction" regarding Xen specific kernel code is towards PVH
and not towards more PV specific tweaking. And I'm very sure the kernel
community outside of the Xen community is agreeing with me here.


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 0/2] xen: Fix PV-only build

[Jason Andryuk]

On 2026-08-06 08:00, Jürgen Groß wrote:
> On 06.08.26 13:31, Jan Beulich wrote:
>> On 06.08.2026 12:55, Juergen Gross wrote:
>>> On 06.08.26 03:52, Jason Andryuk wrote:
>>>> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
>>>> code needs to be fixed first.
>>>>
>>>> Jason Andryuk (2):
>>>>     xen/events: Fix xen_set_upcall_vector stub
>>>>     xen/Kconfig: select XEN_PVHVM
>>>>
>>>>    arch/x86/xen/Kconfig             | 8 +++++---
>>>>    drivers/xen/events/events_base.c | 2 +-
>>>>    2 files changed, 6 insertions(+), 4 deletions(-)
>>>>
>>>
>>> I did a comparison of a kernel built with your patches disabling 
>>> XEN_PVHVM
>>> and my patches with XEN_PVHVM_GUEST disabled.
>>>
>>> The kernel built with my patches is 6 bytes smaller than the one with 
>>> your
>>> patches.
>>
>> Isn't this a sign of something else needing tweaking, somewhere?
> 
> This is a sign that there are probably only very few really HVM specific 
> paths
> (in the sense of: explicitly not marked as irrelevant for PV) in the 
> kernel.
> Yes, I'm sure you can find some more, but I'm really not sure this is 
> relevant
> for more than a handful of users.

I see more reduction:
15029248 - arch/x86/boot/bzImage
15021056 - arch/x86/boot/bzImage.after

~8k

52542480 - vmlinux
52523184 - vmlinux.after

~18k

$ ../linux/scripts/bloat-o-meter vmlinux vmlinux.after
add/remove: 1/136 grow/shrink: 14/48 up/down: 15902/-22430 (-6528)

>>> So I don't see any reason to take your patches, which conflict with 
>>> mine,
>>> especially as my patches have a negative diffstat on source level, too.
>>
>> Hmm, Jason's patches look to move things into a more adequate direction,
>> though. In which case I think a negative diffstat becomes an irrelevant
>> argument?
> 
> Depends on what you are looking for.
> 
> My take from this is that a PV-only kernel with Jason's patches is not 
> really
> adding any value, while my simplification is at least making things simpler
> in terms of code volume and number of Xen related config options.
> 
> Of course it would be possible to have a smaller PV-only kernel, but as 
> I said
> already, there has been no public demand for that in the last years and the
> downsides IMHO far outweigh the potential gain.
> 
> IMO the "adequate direction" regarding Xen specific kernel code is 
> towards PVH
> and not towards more PV specific tweaking. And I'm very sure the kernel
> community outside of the Xen community is agreeing with me here.
I don't need PV-only kernels, so I am fine with not pursuing this patch set.

Mainly I wanted to post this alternative since restoring PV-only is 
possible (and I inadvertently broke it).  Converting CONFIG_XEN_PVHVM to 
CONFIG_XEN looked wrong when it didn't apply to PV.

Pursuing your patches for the reasons you give also makes sense.

Regards,
Jason

Re: [PATCH 0/2] xen: Fix PV-only build

[Juergen Gross]

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

On 06.08.26 15:24, Jason Andryuk wrote:
> On 2026-08-06 08:00, Jürgen Groß wrote:
>> On 06.08.26 13:31, Jan Beulich wrote:
>>> On 06.08.2026 12:55, Juergen Gross wrote:
>>>> On 06.08.26 03:52, Jason Andryuk wrote:
>>>>> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
>>>>> code needs to be fixed first.
>>>>>
>>>>> Jason Andryuk (2):
>>>>>     xen/events: Fix xen_set_upcall_vector stub
>>>>>     xen/Kconfig: select XEN_PVHVM
>>>>>
>>>>>    arch/x86/xen/Kconfig             | 8 +++++---
>>>>>    drivers/xen/events/events_base.c | 2 +-
>>>>>    2 files changed, 6 insertions(+), 4 deletions(-)
>>>>>
>>>>
>>>> I did a comparison of a kernel built with your patches disabling XEN_PVHVM
>>>> and my patches with XEN_PVHVM_GUEST disabled.
>>>>
>>>> The kernel built with my patches is 6 bytes smaller than the one with your
>>>> patches.
>>>
>>> Isn't this a sign of something else needing tweaking, somewhere?
>>
>> This is a sign that there are probably only very few really HVM specific paths
>> (in the sense of: explicitly not marked as irrelevant for PV) in the kernel.
>> Yes, I'm sure you can find some more, but I'm really not sure this is relevant
>> for more than a handful of users.
> 
> I see more reduction:
> 15029248 - arch/x86/boot/bzImage
> 15021056 - arch/x86/boot/bzImage.after
> 
> ~8k
> 
> 52542480 - vmlinux
> 52523184 - vmlinux.after
> 
> ~18k
> 
> $ ../linux/scripts/bloat-o-meter vmlinux vmlinux.after
> add/remove: 1/136 grow/shrink: 14/48 up/down: 15902/-22430 (-6528)

Did you disable CONFIG_XEN_PVHVM_GUEST in the before kernel, too?

> 
>>>> So I don't see any reason to take your patches, which conflict with mine,
>>>> especially as my patches have a negative diffstat on source level, too.
>>>
>>> Hmm, Jason's patches look to move things into a more adequate direction,
>>> though. In which case I think a negative diffstat becomes an irrelevant
>>> argument?
>>
>> Depends on what you are looking for.
>>
>> My take from this is that a PV-only kernel with Jason's patches is not really
>> adding any value, while my simplification is at least making things simpler
>> in terms of code volume and number of Xen related config options.
>>
>> Of course it would be possible to have a smaller PV-only kernel, but as I said
>> already, there has been no public demand for that in the last years and the
>> downsides IMHO far outweigh the potential gain.
>>
>> IMO the "adequate direction" regarding Xen specific kernel code is towards PVH
>> and not towards more PV specific tweaking. And I'm very sure the kernel
>> community outside of the Xen community is agreeing with me here.
> I don't need PV-only kernels, so I am fine with not pursuing this patch set.
> 
> Mainly I wanted to post this alternative since restoring PV-only is possible 
> (and I inadvertently broke it).  Converting CONFIG_XEN_PVHVM to CONFIG_XEN 
> looked wrong when it didn't apply to PV.
> 
> Pursuing your patches for the reasons you give also makes sense.

Thanks,


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 0/2] xen: Fix PV-only build

[Jason Andryuk]

On 2026-08-06 09:31, Juergen Gross wrote:
> On 06.08.26 15:24, Jason Andryuk wrote:
>> On 2026-08-06 08:00, Jürgen Groß wrote:
>>> On 06.08.26 13:31, Jan Beulich wrote:
>>>> On 06.08.2026 12:55, Juergen Gross wrote:
>>>>> On 06.08.26 03:52, Jason Andryuk wrote:
>>>>>> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
>>>>>> code needs to be fixed first.
>>>>>>
>>>>>> Jason Andryuk (2):
>>>>>>     xen/events: Fix xen_set_upcall_vector stub
>>>>>>     xen/Kconfig: select XEN_PVHVM
>>>>>>
>>>>>>    arch/x86/xen/Kconfig             | 8 +++++---
>>>>>>    drivers/xen/events/events_base.c | 2 +-
>>>>>>    2 files changed, 6 insertions(+), 4 deletions(-)
>>>>>>
>>>>>
>>>>> I did a comparison of a kernel built with your patches disabling 
>>>>> XEN_PVHVM
>>>>> and my patches with XEN_PVHVM_GUEST disabled.
>>>>>
>>>>> The kernel built with my patches is 6 bytes smaller than the one 
>>>>> with your
>>>>> patches.
>>>>
>>>> Isn't this a sign of something else needing tweaking, somewhere?
>>>
>>> This is a sign that there are probably only very few really HVM 
>>> specific paths
>>> (in the sense of: explicitly not marked as irrelevant for PV) in the 
>>> kernel.
>>> Yes, I'm sure you can find some more, but I'm really not sure this is 
>>> relevant
>>> for more than a handful of users.
>>
>> I see more reduction:
>> 15029248 - arch/x86/boot/bzImage
>> 15021056 - arch/x86/boot/bzImage.after
>>
>> ~8k
>>
>> 52542480 - vmlinux
>> 52523184 - vmlinux.after
>>
>> ~18k
>>
>> $ ../linux/scripts/bloat-o-meter vmlinux vmlinux.after
>> add/remove: 1/136 grow/shrink: 14/48 up/down: 15902/-22430 (-6528)
> 
> Did you disable CONFIG_XEN_PVHVM_GUEST in the before kernel, too?

Yes

$ grep PVHVM config-before config-after config-pvh-before:CONFIG_XEN_PVHVM=y
config-pvh-before:CONFIG_XEN_PVHVM_SMP=y
config-pvh-before:# CONFIG_XEN_PVHVM_GUEST is not set
config-pvh-after:# CONFIG_XEN_PVHVM_GUEST is not set

These three options change:
$ diff -u config-before config-after
-CONFIG_XEN_PVHVM=y
-CONFIG_XEN_PVHVM_SMP=y
-CONFIG_XEN_AUTO_XLATE=y

Regards,
Jason