From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail187-10.suw11.mandrillapp.com (mail187-10.suw11.mandrillapp.com [198.2.187.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39A5239903D for ; Tue, 24 Feb 2026 12:46:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.2.187.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771937178; cv=none; b=MNUmre83uS4Ny9VoKYm+ciaK32duYL4IEPecqYts5woJLEYO2hWDOBzqFuPPOmnPUgBY5MdBAHt2uHBXROeqBSW8anvzRa+5/QoBArU7i+KqCHtl7OV1dK3tMasNU/QjktF5eOjuGH8G7mocprP3evmjMMfI+LGwqCvcEcyOXMU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771937178; c=relaxed/simple; bh=KXdPKuifM+f88KKJjmS9r3D9OY2yL92m2XuwLa6udTM=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Date: MIME-Version:Content-Type; b=hiNRKphYOo4cIxhRTXK+AN/xR6upt9u22uf1XD9yR6bS4NKJqQIYAFxzTakEQb+YCo6zWb9D+gPADF0x0P0yx7o68K1BF85bDCQIkKByW/LMNyC34Ra0vBTVSJesL1emTiKjHoi/T/wCFcuIlzWdXvkmHfMzkz9L3cix7efsImA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=vates.tech; spf=pass smtp.mailfrom=bounce.vates.tech; dkim=pass (2048-bit key) header.d=mandrillapp.com header.i=@mandrillapp.com header.b=GyQFtOfu; dkim=pass (2048-bit key) header.d=vates.tech header.i=teddy.astie@vates.tech header.b=G6uMm3a6; arc=none smtp.client-ip=198.2.187.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=vates.tech Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bounce.vates.tech Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mandrillapp.com header.i=@mandrillapp.com header.b="GyQFtOfu"; dkim=pass (2048-bit key) header.d=vates.tech header.i=teddy.astie@vates.tech header.b="G6uMm3a6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1771937176; x=1772207176; bh=lXd6UpYAp3t3un2N6Ph54v7LZ+JVCHmjwbvsN8beoWo=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=GyQFtOfuxvoUz7WsszwRxlx/XPgwEfjotX3TxrPR0BRbnzNEZcPYnrPuYUw4wMdJG RYnAOBBjKoRQRNlAcsOrUmRq7W/aa31HTbgYkFnWSI00XiKQe6tCuq3i03iqIm6X62 eQdT4nkXcHjtQQPSGBudEF1d4hM5o2Tcmqk+JHi0pra23/kuZ6M6uR6R7pLmwMMArd TDDGfUp6JCg5GWjUAZnoZbYjR+eGiD5SITp7gKEzLbttPOvLyJRBoP04H7RiOr0rEp m20zldNrqeUKtRL2SnRTZiWQ04rgvWJSxrR7Rw1bD50l++Gr+poDXEkc0JzcPuvfKg QNxW9lPjkCbpw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1771937176; x=1772197676; i=teddy.astie@vates.tech; bh=lXd6UpYAp3t3un2N6Ph54v7LZ+JVCHmjwbvsN8beoWo=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=G6uMm3a6fvJ2Lf1o+4HsoR1C1jqdkLJ70VYSJjCqoXL2T6aSSngTALN/iYMNbpLDn ilJTJQU2lIdfV4iVmmxMaVpw6YHbt/nRFmDOmk+bQp+WVhesSLtRBisQJ+IvssQkT1 U/XC8C5HAfzMKl9zDhOQWA1t8fv+vgB/niwZdTxP3jDvmkzszqyvCD1S3o/P5np07l QClLvHcdeA4j3PORLZ+E/g9kDI+UuWNp7TkcQiDo79fB2/nRWfI4TXJwH1U9w8j1V3 tLOty+8YLtuvSuUWKfaWf6+UtLAUN8Nmh4r9697fc+0DiER8t6dFOSamlvbsjIXOQI OSiL9EvOt8Wtw== Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-10.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4fKyBw3Tjpz5QkLVX for ; Tue, 24 Feb 2026 12:46:16 +0000 (GMT) From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RFC=20PATCH]=20x86/xen:=20Consider=20Xen=20PVH=20support=20in=20CONFIG=5FXEN=5FPVHVM?= Received: from [37.26.189.201] by mandrillapp.com id 2ff1b11cb3fa493ab1c5cf00b2d2ded9; Tue, 24 Feb 2026 12:46:16 +0000 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1771937175070 Message-Id: To: "=?utf-8?Q?J=C3=BCrgen=20Gro=C3=9F?=" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, "Boris Ostrovsky" , "Oleksandr Tyshchenko" References: <7b17bfbb4b25a59514707f91546ce8c3a24369e0.1771929804.git.teddy.astie@vates.tech> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.2ff1b11cb3fa493ab1c5cf00b2d2ded9?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260224:md Date: Tue, 24 Feb 2026 12:46:16 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 24/02/2026 =C3=A0 12:25, J=C3=BCrgen Gro=C3=9F a =C3=A9crit=C2=A0: > On 24.02.26 12:14, Roger Pau Monn=C3=A9 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. >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0 platform_pci_unplug: Xen Platform PCI: unrecog= nised magic value >>> =C2=A0=C2=A0=C2=A0=C2=A0 ... >>> =C2=A0=C2=A0=C2=A0=C2=A0 # modprobe xen-blkfront >>> =C2=A0=C2=A0=C2=A0=C2=A0 modprobe: ERROR: could not insert 'xen_blkfron= t': No such device >>> =C2=A0=C2=A0=C2=A0=C2=A0 # modprobe xen-netfront >>> =C2=A0=C2=A0=C2=A0=C2=A0 modprobe: ERROR: could not insert 'xen_netfron= t': 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 >>> --- >>> Cc: Juergen Gross >>> Cc: Boris Ostrovsky >>> Cc: Oleksandr Tyshchenko >>> >>> 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?=C2=A0 I= s >> the default set to n on the defconfig?=C2=A0 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_PVHV= M. > 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