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 AB5E1C83F1A for ; Wed, 23 Jul 2025 12:02:42 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1053878.1422665 (Exim 4.92) (envelope-from ) id 1ueYB6-0001Fj-2a; Wed, 23 Jul 2025 12:02:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1053878.1422665; Wed, 23 Jul 2025 12:02:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ueYB5-0001Fc-Vs; Wed, 23 Jul 2025 12:02:31 +0000 Received: by outflank-mailman (input) for mailman id 1053878; Wed, 23 Jul 2025 12:02:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ueYB5-0001FW-Ky for xen-devel@lists.xenproject.org; Wed, 23 Jul 2025 12:02:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1ueYB4-00EsfR-1x; Wed, 23 Jul 2025 12:02:30 +0000 Received: from [15.248.2.234] (helo=[10.24.67.34]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ueYB4-009RvH-0r; Wed, 23 Jul 2025 12:02:30 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=3YRiS053T+S8PQj31pQDRgF0vdmdDg9DTwjWARfUqn4=; b=DJm2hMN+1Tc/1wt2U9DZlZoEjg mVbbmEA/Wwm/GRVhHoydAK2Ro82yaBDt0mPbZqK3Q592nKO5DaqRSx6qHFBx4NJjiGv9plWHcfVVR THq3Xt/CMDoXINhoF3RED+WvJu/MkErqVuNKWyYGbtBbSiLJzbNQDd8PNPp5uJ5L9LNs=; Message-ID: <71fa14e0-83d7-48ec-8bd9-258ec8f6cedf@xen.org> Date: Wed, 23 Jul 2025 13:02:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN][PATCH 0/8] xen/arm64: make aarch32 support optional To: Grygorii Strashko , "Orzel, Michal" , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , Roger Pau Monne References: <20250723075835.3993182-1-grygorii_strashko@epam.com> Content-Language: en-US From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 23/07/2025 12:48, Grygorii Strashko wrote: > > > On 23.07.25 13:54, Orzel, Michal wrote: >> >> >> On 23/07/2025 10:06, Julien Grall wrote: >>> >>> >>> On 23/07/2025 08:58, Grygorii Strashko wrote: >>>> From: Grygorii Strashko >>>> >>>> Hi, >>> >>> Hi Grygorii, >>> >>>> Now Arm64 AArch32 guest support is always enabled and built-in while >>>> not >>>> all Arm64 platforms supports AArch32 or this support might not be >>>> needed. >>> >>> I am not entirely sure I like the proliferation of using CONFIG_* for >>> every single feature. This makes the testing a bit more complicated. >>> >>> Can you clarify what the goal with this patch? >> AArch32 is used quite rarely in embedded systems. Also, in Armv9A it >> might only >> be implemented at EL0 if at all. When focusing on safety >> certification, AArch32 >> related code in Xen leaves a gap in terms of coverage that cannot >> really be >> justified in words. This leaves us with two options: either support it >> (lots of >> additional testing, requirements and documents would be needed) or >> compile it out. > > FYI. bloat-o-meter report for this series with CONFIG_ARM64_AARCH32=n, > CONFIG_EXPERT=y Thanks for sharing the bloat-o-meter. But I don't think the result below warrant a new config. The reason provided by Michal is a better reason as the impact on safety certification is more significant. Cheers, -- Julien Grall