Re: [PATCH 0/2] xen: Fix PV-only build
Jason Andryuk <[email protected]> Thu, 6 Aug 2026 09:24:23 -0400
| Newsgroups | gmane.comp.emulators.xen.devel,gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
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