|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH] x86/xen: Consider Xen PVH support in CONFIG_XEN_PVHVM
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@xxxxxxxxxx> --- Cc: Juergen Gross <jgross@xxxxxxxx> Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx> 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 Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc Attachment:
OpenPGP_signature.asc
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |