From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail186-12.suw21.mandrillapp.com (mail186-12.suw21.mandrillapp.com [198.2.186.12]) (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 7E9B31FBEA8 for ; Tue, 24 Feb 2026 12:34:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.2.186.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771936474; cv=none; b=ReDWLSxClgMnQ2oSNdOsNJV34FnVqqEbDaVkasaaX0D+/FCqA5wUkfDWcGMl7nquo5/R5d3pHncEWxn1U2aQsC73gqRk/niGvibkdZBFtebU6RLNkDg5fAuLCjFVgT2hkxKYAtDaszSt13mxqlgmFtN8AFXLLZ6VZ7rMib+WBXc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771936474; c=relaxed/simple; bh=4snjCcVupxbBb3Noa9EJ1klw4a1AJxaZK0JeBx6iIrM=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Date: MIME-Version:Content-Type; b=hOjAwQ0wODhKikS8f9+Ojkw+I+IY1tF7Ckax/WUEzy/jneHbpArhr9NZgNLr52gAjaRb6qwVXE9U1AvTkzg45VOOQQewfvyxRxaf2o9JNu6GDFU7nfskEcGtP5ZVB5gfhMKkhiy5MSBPj3SaIfw5Z5ktdeapZix5eLgm9nF1rCQ= 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=R68FeCrF; dkim=pass (2048-bit key) header.d=vates.tech header.i=teddy.astie@vates.tech header.b=D5kKCx28; arc=none smtp.client-ip=198.2.186.12 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="R68FeCrF"; dkim=pass (2048-bit key) header.d=vates.tech header.i=teddy.astie@vates.tech header.b="D5kKCx28" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1771936472; x=1772206472; bh=s5qi7uPRrfCegLpwk9h+nXdmi/P0H3e2sU4RGf+LcMQ=; 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=R68FeCrFEEAxatJkaRUPSfZFmOV1nONhHD4OgqtyMmUJnqyCZp3WfV/h0UxquqgqT Mqt4BNTnVin3aypZ5W4ZrRxptE6vW8hXQ+HMsXV+c6tDThbyg5c1DdII8ymhaujJGp oD3hwUEGkek/EzWtDYYWGLuOR6CkbYXZXjJJvRtkhdYQBd8mJLKWDkev5drRYSU+1x rXQGimU8Z2x52NQwOHNul2ivGzHzxObl2MO6Xz8YliBv6Ic0+jVqYO4PgEq6GZ1mDB V6UGzX07ESrpAMFJNYTq+VNKJ/TNgEDf4gnOx4hf5dFd8HczTYP/n4Pqk9OEKrtJtp 5iiBKY9vGga4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1771936472; x=1772196972; i=teddy.astie@vates.tech; bh=s5qi7uPRrfCegLpwk9h+nXdmi/P0H3e2sU4RGf+LcMQ=; 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=D5kKCx28xONPo3r2NpigrMCZc+BdJ7Yz2IVWAdOJ/CYkY8DhvOheqwdp/mAzInjy9 90skkDF/+yy1bicT2ZiatWF9DCP8hbyeX+mtH2OI+MLJoH+kv4KI1okU6fBIjNbP8q IjmpRq/EJhOi7A7NiPg9VymG4qn0ifYbRyhvGhueRHCANqx2kEEBaJED3bhyxoBhLW 9yConlS7JAGVr4itTlllYaAHHe/Oz7VnesM8AIf0aAFXmd26almwxbVSKdMsraf+Av mj5cnZKezsjrPUvgISnB7ici9GolrgOvRL1++uCXajqsW1jCoQWRN8s3LLJZyPo3Cv whRXmk+t0ctQA== Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail186-12.suw21.mandrillapp.com (Mailchimp) with ESMTP id 4fKxxN4HCrz705b5v for ; Tue, 24 Feb 2026 12:34:32 +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 499ea883315040858f17c8725272a028; Tue, 24 Feb 2026 12:34:32 +0000 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1771936470614 Message-Id: <962fa327-2e9f-41e5-8382-71ace6fb0a10@vates.tech> To: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, "Juergen Gross" , "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.499ea883315040858f17c8725272a028?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260224:md Date: Tue, 24 Feb 2026 12:34:32 +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:16, Roger Pau Monn=C3=A9 a =C3=A9crit=C2=A0: > 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 wit= h >> "Missing xen PVH initialization" when booting using PVH boot method or >> display various errors and fail to initialize Xen PV drivers when bootin= g >> 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 w= e 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 sup= port >> 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 P= VHVM. >> >> 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 p= art, >> keeping CONFIG_XEN_PVH as a shortcut is interesting, but there may be ot= her >> options. >> >> There are widespreadly used Linux distributions that have a similar conf= iguration >> 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=3Dy > CONFIG_XEN_PVHVM=3Dy 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