mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jürgen Groß" <jgross@suse.com>
To: "Teddy Astie" <teddy.astie@vates.tech>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [RFC PATCH] x86/xen: Consider Xen PVH support in CONFIG_XEN_PVHVM
Date: Tue, 24 Feb 2026 14:53:23 +0100	[thread overview]
Message-ID: <c317c1ee-82d9-4e9d-9c47-fb474527b5ae@suse.com> (raw)
In-Reply-To: <d4ff30fe-4770-49a7-8f80-3e45370b682a@vates.tech>


[-- Attachment #1.1.1: Type: text/plain, Size: 4309 bytes --]

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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

  reply	other threads:[~2026-02-24 13:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24 10:51 Teddy Astie
2026-02-24 11:01 ` Jan Beulich
2026-02-24 11:13   ` Jürgen Groß
2026-02-24 11:14 ` Roger Pau Monné
2026-02-24 11:23   ` Jürgen Groß
2026-02-24 12:46     ` Teddy Astie
2026-02-24 13:53       ` Jürgen Groß [this message]
2026-02-24 12:34   ` Teddy Astie
2026-02-24 14:26     ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c317c1ee-82d9-4e9d-9c47-fb474527b5ae@suse.com \
    --to=jgross@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=roger.pau@citrix.com \
    --cc=teddy.astie@vates.tech \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®