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

[Jason Andryuk <jason.andryuk@amd.com>]

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