arch/x86/xen/Kconfig | 8 +++++--- drivers/xen/events/events_base.c | 2 +- 2 files changed, 6 insertions(+), 4 deletions(-)
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
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.