arch/x86/xen/Makefile | 2 +- arch/x86/xen/enlighten_hvm.c | 2 -- arch/x86/xen/grant-table.c | 2 +- arch/x86/xen/xen-head.S | 8 ++++---- include/xen/xen.h | 2 +- 5 files changed, 7 insertions(+), 9 deletions(-)
It's currently possible to build Linux with CONFIG_PVH|CONFIG_XEN_PVHVM
and no CONFIG_XEN_PVH. That leads to inconsistent kernels that fails with
"Missing xen PVH initialization" when booting using PVH boot method or
display various errors and fail to initialize Xen PV drivers when booting
with PVH-GRUB.
platform_pci_unplug: Xen Platform PCI: unrecognised magic value
...
# modprobe xen-blkfront
modprobe: ERROR: could not insert 'xen_blkfront': No such device
# modprobe xen-netfront
modprobe: ERROR: could not insert 'xen_netfront': No such device
When built without CONFIG_XEN_PVH, PVH-specific logic is disabled, hence when
booting with e.g PVH-OVMF, Linux assumes we are a HVM guest, even when we aren't
actually one (in the "with HVM emulated devices" sense).
As it is actually possible to boot Xen PVH without CONFIG_PVH; and that most
Xen-related logic exist within CONFIG_XEN_PVHVM; consider PVH guests support
within CONFIG_XEN_PVHVM instead of CONFIG_XEN_PVH.
Keep CONFIG_XEN_PVH as a shortcut to enable PVH boot, ACPI support and PVHVM.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
Cc: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
A tentative patch, I'm not sure of the way of dealing with the KConfig part,
keeping CONFIG_XEN_PVH as a shortcut is interesting, but there may be other
options.
There are widespreadly used Linux distributions that have a similar configuration
to this one, thus exhibit this issue i.e fail to boot.
I'm not sure which commit to target for a Fixes: note.
arch/x86/xen/Makefile | 2 +-
arch/x86/xen/enlighten_hvm.c | 2 --
arch/x86/xen/grant-table.c | 2 +-
arch/x86/xen/xen-head.S | 8 ++++----
include/xen/xen.h | 2 +-
5 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index a9ec8c9f5c5d..7fbe17c8ba89 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -33,7 +33,7 @@ obj-$(CONFIG_XEN_PV) += irq.o
obj-$(CONFIG_XEN_PV) += multicalls.o
obj-$(CONFIG_XEN_PV) += xen-asm.o
-obj-$(CONFIG_XEN_PVH) += enlighten_pvh.o
+obj-$(CONFIG_XEN_PVHVM) += enlighten_pvh.o
obj-$(CONFIG_EVENT_TRACING) += trace.o
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index fe57ff85d004..38c2cdfdcc44 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -264,7 +264,6 @@ static bool __init msi_ext_dest_id(void)
static __init void xen_hvm_guest_late_init(void)
{
-#ifdef CONFIG_XEN_PVH
/* Test for PVH domain (PVH boot path taken overrides ACPI flags). */
if (!xen_pvh &&
(x86_platform.legacy.rtc || !x86_platform.legacy.no_vga))
@@ -282,7 +281,6 @@ static __init void xen_hvm_guest_late_init(void)
machine_ops.emergency_restart = xen_emergency_restart;
pv_info.name = "Xen PVH";
-#endif
}
static uint32_t __init xen_platform_hvm(void)
diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 5f4060b5a40d..4d717c92b624 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -149,7 +149,7 @@ int arch_gnttab_init(unsigned long nr_shared, unsigned long nr_status)
return -ENOMEM;
}
-#ifdef CONFIG_XEN_PVH
+#ifdef CONFIG_XEN_PVHVM
#include <xen/events.h>
#include <xen/xen-ops.h>
static int __init xen_pvh_gnttab_setup(void)
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 5dad6c51cdc3..e262caac3ca9 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -162,10 +162,10 @@ SYM_FUNC_END(xen_hypercall_intel)
#else
# define FEATURES_PV 0
#endif
-#ifdef CONFIG_XEN_PVH
-# define FEATURES_PVH (1 << XENFEAT_linux_rsdp_unrestricted)
+#ifdef CONFIG_XEN_PVHVM
+# define FEATURES_PVHVM (1 << XENFEAT_linux_rsdp_unrestricted)
#else
-# define FEATURES_PVH 0
+# define FEATURES_PVHVM 0
#endif
#ifdef CONFIG_XEN_DOM0
# define FEATURES_DOM0 (1 << XENFEAT_dom0)
@@ -173,7 +173,7 @@ SYM_FUNC_END(xen_hypercall_intel)
# define FEATURES_DOM0 0
#endif
ELFNOTE(Xen, XEN_ELFNOTE_SUPPORTED_FEATURES,
- .long FEATURES_PV | FEATURES_PVH | FEATURES_DOM0)
+ .long FEATURES_PV | FEATURES_PVHVM | FEATURES_DOM0)
ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic")
ELFNOTE(Xen, XEN_ELFNOTE_SUSPEND_CANCEL, .long 1)
diff --git a/include/xen/xen.h b/include/xen/xen.h
index f280c5dcf923..4d066fbf9714 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -16,7 +16,7 @@ extern enum xen_domain_type xen_domain_type;
#define xen_domain_type XEN_NATIVE
#endif
-#ifdef CONFIG_XEN_PVH
+#ifdef CONFIG_XEN_PVHVM
extern bool xen_pvh;
#else
#define xen_pvh 0
--
2.53.0
--
Teddy Astie | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.techOn Tue, Feb 24, 2026 at 10:51:35AM +0000, Teddy Astie wrote: > It's currently possible to build Linux with CONFIG_PVH|CONFIG_XEN_PVHVM > and no CONFIG_XEN_PVH. That leads to inconsistent kernels that fails with > "Missing xen PVH initialization" when booting using PVH boot method or > display various errors and fail to initialize Xen PV drivers when booting > with PVH-GRUB. > > platform_pci_unplug: Xen Platform PCI: unrecognised magic value > ... > # modprobe xen-blkfront > modprobe: ERROR: could not insert 'xen_blkfront': No such device > # modprobe xen-netfront > modprobe: ERROR: could not insert 'xen_netfront': No such device > > When built without CONFIG_XEN_PVH, PVH-specific logic is disabled, hence when > booting with e.g PVH-OVMF, Linux assumes we are a HVM guest, even when we aren't > actually one (in the "with HVM emulated devices" sense). > > As it is actually possible to boot Xen PVH without CONFIG_PVH; and that most > Xen-related logic exist within CONFIG_XEN_PVHVM; consider PVH guests support > within CONFIG_XEN_PVHVM instead of CONFIG_XEN_PVH. So the current CONFIG_PVH selection done by CONFIG_XEN_PVH is moot? > Keep CONFIG_XEN_PVH as a shortcut to enable PVH boot, ACPI support and PVHVM. > > Signed-off-by: Teddy Astie <teddy.astie@vates.tech> > --- > Cc: Juergen Gross <jgross@suse.com> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > A tentative patch, I'm not sure of the way of dealing with the KConfig part, > keeping CONFIG_XEN_PVH as a shortcut is interesting, but there may be other > options. > > There are widespreadly used Linux distributions that have a similar configuration > to this one, thus exhibit this issue i.e fail to boot. Do you know the underlying cause of not enabling CONFIG_XEN_PVH? Is the default set to n on the defconfig? Or are distros specifically disabling this option on purpose? It seems like a step backwards to merge this into some bigger generic option, we always try to fine-grain as much as possible. Maybe you could introduce XEN_HVM meta option, that selects both PVHVM and PVH? Thanks, Roger.
Le 24/02/2026 à 12:16, Roger Pau Monné a écrit : > On Tue, Feb 24, 2026 at 10:51:35AM +0000, Teddy Astie wrote: >> It's currently possible to build Linux with CONFIG_PVH|CONFIG_XEN_PVHVM >> and no CONFIG_XEN_PVH. That leads to inconsistent kernels that fails with >> "Missing xen PVH initialization" when booting using PVH boot method or >> display various errors and fail to initialize Xen PV drivers when booting >> with PVH-GRUB. >> >> platform_pci_unplug: Xen Platform PCI: unrecognised magic value >> ... >> # modprobe xen-blkfront >> modprobe: ERROR: could not insert 'xen_blkfront': No such device >> # modprobe xen-netfront >> modprobe: ERROR: could not insert 'xen_netfront': No such device >> >> When built without CONFIG_XEN_PVH, PVH-specific logic is disabled, hence when >> booting with e.g PVH-OVMF, Linux assumes we are a HVM guest, even when we aren't >> actually one (in the "with HVM emulated devices" sense). >> >> As it is actually possible to boot Xen PVH without CONFIG_PVH; and that most >> Xen-related logic exist within CONFIG_XEN_PVHVM; consider PVH guests support >> within CONFIG_XEN_PVHVM instead of CONFIG_XEN_PVH. > > So the current CONFIG_PVH selection done by CONFIG_XEN_PVH is moot? > >> Keep CONFIG_XEN_PVH as a shortcut to enable PVH boot, ACPI support and PVHVM. >> >> Signed-off-by: Teddy Astie <teddy.astie@vates.tech> >> --- >> Cc: Juergen Gross <jgross@suse.com> >> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> >> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >> >> A tentative patch, I'm not sure of the way of dealing with the KConfig part, >> keeping CONFIG_XEN_PVH as a shortcut is interesting, but there may be other >> options. >> >> There are widespreadly used Linux distributions that have a similar configuration >> to this one, thus exhibit this issue i.e fail to boot. > > Do you know the underlying cause of not enabling CONFIG_XEN_PVH? Is > the default set to n on the defconfig? Or are distros specifically > disabling this option on purpose? > I'm observing in these distros that > # CONFIG_XEN_PVH is not set > CONFIG_XEN_PVHVM_GUEST=y > CONFIG_XEN_PVHVM=y Which makes CONFIG_XEN_PVH defaults to n. > It seems like a step backwards to merge this into some bigger generic > option, we always try to fine-grain as much as possible. > > Maybe you could introduce XEN_HVM meta option, that selects both PVHVM > and PVH? > > Thanks, Roger. > Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
On Tue, Feb 24, 2026 at 12:34:31PM +0000, Teddy Astie wrote: > Le 24/02/2026 à 12:16, Roger Pau Monné a écrit : > > On Tue, Feb 24, 2026 at 10:51:35AM +0000, Teddy Astie wrote: > >> It's currently possible to build Linux with CONFIG_PVH|CONFIG_XEN_PVHVM > >> and no CONFIG_XEN_PVH. That leads to inconsistent kernels that fails with > >> "Missing xen PVH initialization" when booting using PVH boot method or > >> display various errors and fail to initialize Xen PV drivers when booting > >> with PVH-GRUB. > >> > >> platform_pci_unplug: Xen Platform PCI: unrecognised magic value > >> ... > >> # modprobe xen-blkfront > >> modprobe: ERROR: could not insert 'xen_blkfront': No such device > >> # modprobe xen-netfront > >> modprobe: ERROR: could not insert 'xen_netfront': No such device > >> > >> When built without CONFIG_XEN_PVH, PVH-specific logic is disabled, hence when > >> booting with e.g PVH-OVMF, Linux assumes we are a HVM guest, even when we aren't > >> actually one (in the "with HVM emulated devices" sense). > >> > >> As it is actually possible to boot Xen PVH without CONFIG_PVH; and that most > >> Xen-related logic exist within CONFIG_XEN_PVHVM; consider PVH guests support > >> within CONFIG_XEN_PVHVM instead of CONFIG_XEN_PVH. > > > > So the current CONFIG_PVH selection done by CONFIG_XEN_PVH is moot? > > > >> Keep CONFIG_XEN_PVH as a shortcut to enable PVH boot, ACPI support and PVHVM. > >> > >> Signed-off-by: Teddy Astie <teddy.astie@vates.tech> > >> --- > >> Cc: Juergen Gross <jgross@suse.com> > >> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > >> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > >> > >> A tentative patch, I'm not sure of the way of dealing with the KConfig part, > >> keeping CONFIG_XEN_PVH as a shortcut is interesting, but there may be other > >> options. > >> > >> There are widespreadly used Linux distributions that have a similar configuration > >> to this one, thus exhibit this issue i.e fail to boot. > > > > Do you know the underlying cause of not enabling CONFIG_XEN_PVH? Is > > the default set to n on the defconfig? Or are distros specifically > > disabling this option on purpose? > > > > I'm observing in these distros that > > > # CONFIG_XEN_PVH is not set > > CONFIG_XEN_PVHVM_GUEST=y > > CONFIG_XEN_PVHVM=y > > Which makes CONFIG_XEN_PVH defaults to n. We should possibly send a patch to those distros Kconfig to enable CONFIG_XEN_PVH? I think it's a bug on their side that Xen PVH is not enabled. Us trying to workaround this in our Linux Kconfig options seem wrong. Thanks, Roger.
On 24.02.26 12:14, Roger Pau Monné wrote: > On Tue, Feb 24, 2026 at 10:51:35AM +0000, Teddy Astie wrote: >> It's currently possible to build Linux with CONFIG_PVH|CONFIG_XEN_PVHVM >> and no CONFIG_XEN_PVH. That leads to inconsistent kernels that fails with >> "Missing xen PVH initialization" when booting using PVH boot method or >> display various errors and fail to initialize Xen PV drivers when booting >> with PVH-GRUB. >> >> platform_pci_unplug: Xen Platform PCI: unrecognised magic value >> ... >> # modprobe xen-blkfront >> modprobe: ERROR: could not insert 'xen_blkfront': No such device >> # modprobe xen-netfront >> modprobe: ERROR: could not insert 'xen_netfront': No such device >> >> When built without CONFIG_XEN_PVH, PVH-specific logic is disabled, hence when >> booting with e.g PVH-OVMF, Linux assumes we are a HVM guest, even when we aren't >> actually one (in the "with HVM emulated devices" sense). >> >> As it is actually possible to boot Xen PVH without CONFIG_PVH; and that most >> Xen-related logic exist within CONFIG_XEN_PVHVM; consider PVH guests support >> within CONFIG_XEN_PVHVM instead of CONFIG_XEN_PVH. > > So the current CONFIG_PVH selection done by CONFIG_XEN_PVH is moot? No, it isn't. CONFIG_PVH is the common base needed for Xen and KVM guests to be able to run in PVH mode. > >> Keep CONFIG_XEN_PVH as a shortcut to enable PVH boot, ACPI support and PVHVM. >> >> Signed-off-by: Teddy Astie <teddy.astie@vates.tech> >> --- >> Cc: Juergen Gross <jgross@suse.com> >> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> >> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >> >> A tentative patch, I'm not sure of the way of dealing with the KConfig part, >> keeping CONFIG_XEN_PVH as a shortcut is interesting, but there may be other >> options. >> >> There are widespreadly used Linux distributions that have a similar configuration >> to this one, thus exhibit this issue i.e fail to boot. > > Do you know the underlying cause of not enabling CONFIG_XEN_PVH? Is > the default set to n on the defconfig? Or are distros specifically > disabling this option on purpose? > > It seems like a step backwards to merge this into some bigger generic > option, we always try to fine-grain as much as possible. > > Maybe you could introduce XEN_HVM meta option, that selects both PVHVM > and PVH? No, please don't use "HVM" for that purpose. If anything I'd set the CONFIG_XEN_PVH default to that of CONFIG_XEN_PVHVM. Juergen
Le 24/02/2026 à 12:25, Jürgen Groß a écrit : > On 24.02.26 12:14, Roger Pau Monné wrote: >> On Tue, Feb 24, 2026 at 10:51:35AM +0000, Teddy Astie wrote: >>> It's currently possible to build Linux with CONFIG_PVH|CONFIG_XEN_PVHVM >>> and no CONFIG_XEN_PVH. That leads to inconsistent kernels that fails >>> with >>> "Missing xen PVH initialization" when booting using PVH boot method or >>> display various errors and fail to initialize Xen PV drivers when >>> booting >>> with PVH-GRUB. >>> >>> platform_pci_unplug: Xen Platform PCI: unrecognised magic value >>> ... >>> # modprobe xen-blkfront >>> modprobe: ERROR: could not insert 'xen_blkfront': No such device >>> # modprobe xen-netfront >>> modprobe: ERROR: could not insert 'xen_netfront': No such device >>> >>> When built without CONFIG_XEN_PVH, PVH-specific logic is disabled, >>> hence when >>> booting with e.g PVH-OVMF, Linux assumes we are a HVM guest, even >>> when we aren't >>> actually one (in the "with HVM emulated devices" sense). >>> >>> As it is actually possible to boot Xen PVH without CONFIG_PVH; and >>> that most >>> Xen-related logic exist within CONFIG_XEN_PVHVM; consider PVH guests >>> support >>> within CONFIG_XEN_PVHVM instead of CONFIG_XEN_PVH. >> >> So the current CONFIG_PVH selection done by CONFIG_XEN_PVH is moot? > > No, it isn't. > > CONFIG_PVH is the common base needed for Xen and KVM guests to be able to > run in PVH mode. > To me, CONFIG_PVH is more about being able to boot using PVH Direct Boot than something else. >> >>> Keep CONFIG_XEN_PVH as a shortcut to enable PVH boot, ACPI support >>> and PVHVM. >>> >>> Signed-off-by: Teddy Astie <teddy.astie@vates.tech> >>> --- >>> Cc: Juergen Gross <jgross@suse.com> >>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> >>> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >>> >>> A tentative patch, I'm not sure of the way of dealing with the >>> KConfig part, >>> keeping CONFIG_XEN_PVH as a shortcut is interesting, but there may be >>> other >>> options. >>> >>> There are widespreadly used Linux distributions that have a similar >>> configuration >>> to this one, thus exhibit this issue i.e fail to boot. >> >> Do you know the underlying cause of not enabling CONFIG_XEN_PVH? Is >> the default set to n on the defconfig? Or are distros specifically >> disabling this option on purpose? >> >> It seems like a step backwards to merge this into some bigger generic >> option, we always try to fine-grain as much as possible. >> >> Maybe you could introduce XEN_HVM meta option, that selects both PVHVM >> and PVH? > No, please don't use "HVM" for that purpose. > > If anything I'd set the CONFIG_XEN_PVH default to that of CONFIG_XEN_PVHVM. > That could work, but that would transitively imply that CONFIG_XEN needs CONFIG_PVH, which I guess we probably want to avoid. As I said, it's not required to boot with "PVH direct boot" for a "PVH guest personality" to work in Linux since [1]. We can eventually consider decoupling CONFIG_XEN_PVH and CONFIG_PVH, but that would break setup that expects that CONFIG_XEN_PVH implies CONFIG_PVH (arch/x86/configs/xen.config in particular). [1] 418492ba "x86/virt/xen: Use guest_late_init to detect Xen PVH guest" > > Juergen Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
On 24.02.26 13:46, Teddy Astie wrote: > Le 24/02/2026 à 12:25, Jürgen Groß a écrit : >> On 24.02.26 12:14, Roger Pau Monné wrote: >>> On Tue, Feb 24, 2026 at 10:51:35AM +0000, Teddy Astie wrote: >>>> It's currently possible to build Linux with CONFIG_PVH|CONFIG_XEN_PVHVM >>>> and no CONFIG_XEN_PVH. That leads to inconsistent kernels that fails >>>> with >>>> "Missing xen PVH initialization" when booting using PVH boot method or >>>> display various errors and fail to initialize Xen PV drivers when >>>> booting >>>> with PVH-GRUB. >>>> >>>> platform_pci_unplug: Xen Platform PCI: unrecognised magic value >>>> ... >>>> # modprobe xen-blkfront >>>> modprobe: ERROR: could not insert 'xen_blkfront': No such device >>>> # modprobe xen-netfront >>>> modprobe: ERROR: could not insert 'xen_netfront': No such device >>>> >>>> When built without CONFIG_XEN_PVH, PVH-specific logic is disabled, >>>> hence when >>>> booting with e.g PVH-OVMF, Linux assumes we are a HVM guest, even >>>> when we aren't >>>> actually one (in the "with HVM emulated devices" sense). >>>> >>>> As it is actually possible to boot Xen PVH without CONFIG_PVH; and >>>> that most >>>> Xen-related logic exist within CONFIG_XEN_PVHVM; consider PVH guests >>>> support >>>> within CONFIG_XEN_PVHVM instead of CONFIG_XEN_PVH. >>> >>> So the current CONFIG_PVH selection done by CONFIG_XEN_PVH is moot? >> >> No, it isn't. >> >> CONFIG_PVH is the common base needed for Xen and KVM guests to be able to >> run in PVH mode. >> > > To me, CONFIG_PVH is more about being able to boot using PVH Direct Boot > than something else. This is one aspect of it, yes. > >>> >>>> Keep CONFIG_XEN_PVH as a shortcut to enable PVH boot, ACPI support >>>> and PVHVM. >>>> >>>> Signed-off-by: Teddy Astie <teddy.astie@vates.tech> >>>> --- >>>> Cc: Juergen Gross <jgross@suse.com> >>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> >>>> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >>>> >>>> A tentative patch, I'm not sure of the way of dealing with the >>>> KConfig part, >>>> keeping CONFIG_XEN_PVH as a shortcut is interesting, but there may be >>>> other >>>> options. >>>> >>>> There are widespreadly used Linux distributions that have a similar >>>> configuration >>>> to this one, thus exhibit this issue i.e fail to boot. >>> >>> Do you know the underlying cause of not enabling CONFIG_XEN_PVH? Is >>> the default set to n on the defconfig? Or are distros specifically >>> disabling this option on purpose? >>> >>> It seems like a step backwards to merge this into some bigger generic >>> option, we always try to fine-grain as much as possible. >>> >>> Maybe you could introduce XEN_HVM meta option, that selects both PVHVM >>> and PVH? >> No, please don't use "HVM" for that purpose. >> >> If anything I'd set the CONFIG_XEN_PVH default to that of CONFIG_XEN_PVHVM. >> > > That could work, but that would transitively imply that CONFIG_XEN needs > CONFIG_PVH, which I guess we probably want to avoid. I don't see that (neither the dependency of CONFIG_XEN on CONFIG_PVH, nor that it is a problem that CONFIG_XEN_PVH depends on CONFIG_PVH). > As I said, it's not required to boot with "PVH direct boot" for a "PVH > guest personality" to work in Linux since [1]. Please be aware that this was needed back then in order to be able to use a boot loader for booting as PVH guest. With the addition of grub-xenpvh (which was more than one year later) the preferred way to boot a Xen PVH guest was to use that grub flavor, which is using the PVH specific entry point of the kernel. Even later qemu was enhanced to boot the kernel via the same entry point when using KVM. That was the time when the CONFIG_PVH code was carved out from the CONFIG_XEN_PVH code. > We can eventually consider decoupling CONFIG_XEN_PVH and CONFIG_PVH, but > that would break setup that expects that CONFIG_XEN_PVH implies > CONFIG_PVH (arch/x86/configs/xen.config in particular). Historically and technically I'd consider the CONFIG_PVH specific parts as mandatory Xen PVH mode kernel code. Not being able to boot via grub-xenpvh would be a major regression. Juergen
On 24.02.2026 11:51, Teddy Astie wrote: > It's currently possible to build Linux with CONFIG_PVH|CONFIG_XEN_PVHVM > and no CONFIG_XEN_PVH. In which case, how can you expect Xen PVH to work? > That leads to inconsistent kernels that fails with > "Missing xen PVH initialization" when booting using PVH boot method or > display various errors and fail to initialize Xen PV drivers when booting > with PVH-GRUB. > > platform_pci_unplug: Xen Platform PCI: unrecognised magic value > ... > # modprobe xen-blkfront > modprobe: ERROR: could not insert 'xen_blkfront': No such device > # modprobe xen-netfront > modprobe: ERROR: could not insert 'xen_netfront': No such device > > When built without CONFIG_XEN_PVH, PVH-specific logic is disabled, hence when > booting with e.g PVH-OVMF, Linux assumes we are a HVM guest, even when we aren't > actually one (in the "with HVM emulated devices" sense). > > As it is actually possible to boot Xen PVH without CONFIG_PVH; and that most > Xen-related logic exist within CONFIG_XEN_PVHVM; consider PVH guests support > within CONFIG_XEN_PVHVM instead of CONFIG_XEN_PVH. XEN_PVHVM serves a different purpose though, iirc. Jan
On 24.02.26 12:01, Jan Beulich wrote: > On 24.02.2026 11:51, Teddy Astie wrote: >> It's currently possible to build Linux with CONFIG_PVH|CONFIG_XEN_PVHVM >> and no CONFIG_XEN_PVH. > > In which case, how can you expect Xen PVH to work? I agree. Similar to a kernel not working properly on AMD when configured to support INTEL cpus only. > >> That leads to inconsistent kernels that fails with >> "Missing xen PVH initialization" when booting using PVH boot method or >> display various errors and fail to initialize Xen PV drivers when booting >> with PVH-GRUB. >> >> platform_pci_unplug: Xen Platform PCI: unrecognised magic value >> ... >> # modprobe xen-blkfront >> modprobe: ERROR: could not insert 'xen_blkfront': No such device >> # modprobe xen-netfront >> modprobe: ERROR: could not insert 'xen_netfront': No such device >> >> When built without CONFIG_XEN_PVH, PVH-specific logic is disabled, hence when >> booting with e.g PVH-OVMF, Linux assumes we are a HVM guest, even when we aren't >> actually one (in the "with HVM emulated devices" sense). >> >> As it is actually possible to boot Xen PVH without CONFIG_PVH; and that most >> Xen-related logic exist within CONFIG_XEN_PVHVM; consider PVH guests support >> within CONFIG_XEN_PVHVM instead of CONFIG_XEN_PVH. > > XEN_PVHVM serves a different purpose though, iirc. I does. CONFIG_XEN_PVH depends on CONFIG_XEN_PVHVM exactly because a lot of the logic required for PVH mode was implemented as a performance tweak of HVM under the CONFIG_XEN_PVHVM umbrella. In case you want to boot as a working PVH guest, you need a kernel configured with CONFIG_XEN_PVH. It is that simple. Its a NACK from me. Juergen
© 2016 - 2026 Red Hat, Inc.