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

[Jason Andryuk <jason.andryuk@xxxxxxx>]

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