From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 87F96C87FCA for ; Tue, 29 Jul 2025 22:10:24 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1063196.1428994 (Exim 4.92) (envelope-from ) id 1ugsWT-0002Ht-1q; Tue, 29 Jul 2025 22:10:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1063196.1428994; Tue, 29 Jul 2025 22:10:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ugsWS-0002Hm-U4; Tue, 29 Jul 2025 22:10:12 +0000 Received: by outflank-mailman (input) for mailman id 1063196; Tue, 29 Jul 2025 22:10:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ugsWQ-0000tb-Q0 for xen-devel@lists.xenproject.org; Tue, 29 Jul 2025 22:10:11 +0000 Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch [79.135.106.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ca0d014e-6cc8-11f0-b895-0df219b8e170; Wed, 30 Jul 2025 00:10:09 +0200 (CEST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ca0d014e-6cc8-11f0-b895-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1753827007; x=1754086207; bh=KpeawhcIzhNTOwabM6HfpqyvSLAj9mVYFxmAEkEl7TM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=dPKqRcdTo9eMdhS9pT6sBbEgTprYE1YYk58bx1jtqfQAhXe+FnCUYSt3OSdbDxZMP ZFbilvRFD1z5K0nVKAwKcgfiwaEoiifhYEvp86P1Yf995ljiR2Gpn+T3F6Ccmavtny 3xo0xzhFDBflLeKQAq+hPZ7wGDNWx/3GX4wuJtuZR55ypV/9Swj9ltMtDjeztR+rc8 lesPmhYMwHJSM3v1i0xlrypv7MpYP5yeUbvhPjtlmOmhe6FbTqn1nG3wg3svId4PSk ssJYkakgrbjnHu2bQ+CeFhC1cJ2YTesxziBi3AkKfmX0O193eniPJvI2tK5ezgq+03 x6Et6OTTooQYw== Date: Tue, 29 Jul 2025 22:10:02 +0000 To: Jan Beulich From: dmkhn@proton.me Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Julien Grall , Michal Orzel , =?utf-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Oleksandr Tyshchenko , Oleksii Moisieiev Subject: Re: [PATCH v2] xen/arm, xen/common: Add Kconfig option to control Dom0 boot Message-ID: In-Reply-To: <182d2b92-ba93-4916-a277-d7996b784fa2@suse.com> References: <90e79e175b5f703f33944415df3c7a73d6abc385.1753722403.git.oleksii_moisieiev@epam.com> <182d2b92-ba93-4916-a277-d7996b784fa2@suse.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: 563b818cef7941a368460e08b2c073c503190411 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 29, 2025 at 10:20:54AM +0200, Jan Beulich wrote: > On 28.07.2025 23:28, dmkhn@proton.me wrote: > > On Mon, Jul 28, 2025 at 05:07:30PM +0000, Oleksii Moisieiev wrote: > >> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to > >> allow for building Xen without support for booting a regular domain (D= om0). > >> This functionality is primarily intended for the ARM architecture. > >> > >> A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by > >> default for ARM and X86 architecture. This symbol signifies that an > >> architecture has the capability to support a Dom0. > >> > >> The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For > >> expert users, this option can be disabled (`CONFIG_EXPERT=3Dy` and no > >> `CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0 > >> creation code on ARM. This is useful for embedded or dom0less-only > >> scenarios to reduce binary size and complexity. > >> > >> The ARM boot path has been updated to panic if it detects a non-dom0le= ss > >> configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an inva= lid > >> boot. > >> > >> Signed-off-by: Oleksii Moisieiev > >> > >> --- > >> > >> --- > >> xen/arch/arm/Kconfig | 1 + > >> xen/arch/arm/domain_build.c | 8 ++++++++ > >> xen/arch/arm/setup.c | 14 ++++++++++---- > >> xen/arch/x86/Kconfig | 1 + > >> xen/common/Kconfig | 11 +++++++++++ > >> 5 files changed, 31 insertions(+), 4 deletions(-) > > > > I think there should be changes in > > include/xen/domain.h > > and > > arch/arm/include/asm/setup.h > > to compile out declarations of dom0_max_vcpus() and create_dom0() under= new > > CONFIG_DOM0_BOOT. >=20 > Adding #ifdef-ary just to hide declarations is often merely adding clutte= r, > without providing a clear benefit. I didn't check in this case, but I thi= nk > when making such a request you want to clarify what the gains would be of > adding more #ifdef. re: clutter: fully agree. I was thinking about this following code where ifdef-ery may be needed: + if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() ) + { + /* Create initial domain 0. */ create_dom0(); + } But looks like compiler is correctly throwing away create_dom0() call. >=20 > Jan