Re: [RFC PATCH] x86/xen: Consider Xen PVH support in CONFIG_XEN_PVHVM
From: Jürgen Groß
Date: Tue Feb 24 2026 - 09:01:19 EST
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.
No, please don't use "HVM" for that purpose.
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?
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
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature