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 X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00BAEC4338F for ; Fri, 20 Aug 2021 14:42:00 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id AC91C60F39 for ; Fri, 20 Aug 2021 14:42:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AC91C60F39 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.169570.309767 (Exim 4.92) (envelope-from ) id 1mH5iM-0000WR-SD; Fri, 20 Aug 2021 14:41:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 169570.309767; Fri, 20 Aug 2021 14:41:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mH5iM-0000WK-OE; Fri, 20 Aug 2021 14:41:46 +0000 Received: by outflank-mailman (input) for mailman id 169570; Fri, 20 Aug 2021 14:41:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mH5iL-0000WE-F5 for xen-devel@lists.xenproject.org; Fri, 20 Aug 2021 14:41:45 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mH5iL-0004X1-9r; Fri, 20 Aug 2021 14:41:45 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mH5iL-0004Ug-42; Fri, 20 Aug 2021 14:41:45 +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: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=lk5MHqeag5VsFqUhgTDJIKvQ4yZc4+EvU1tREyHhZxg=; b=se/M1ZhEzkrrcUMWbeC4l4pWbe JD7YtUgjRGA//O2wvoVhgmqioKK4dfaSJbxk4Q2pA8FHLp0azveQw8/JPa+64++heChcVnpowEf/X 17WlwrGI7Urew3bnPRZXxV67VU5/EFoJA/44EZDy9tKtHZMH9GSJq7mb9kh2QlYJRaAI=; Subject: Re: [XEN RFC PATCH 07/40] xen/arm: use !CONFIG_NUMA to keep fake NUMA API To: Wei Chen , "xen-devel@lists.xenproject.org" , "sstabellini@kernel.org" Cc: Bertrand Marquis References: <20210811102423.28908-1-wei.chen@arm.com> <20210811102423.28908-8-wei.chen@arm.com> <4de5b7ed-ada5-2114-2002-7f5e26a89417@xen.org> <54707c92-3bda-60b8-4b36-1eae172cacb1@xen.org> From: Julien Grall Message-ID: <12065cae-6dd4-84c9-d6c7-2e901cf50a6a@xen.org> Date: Fri, 20 Aug 2021 15:41:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit On 20/08/2021 13:23, Wei Chen wrote: > Hi Julien, Hi Wei, >> -----Original Message----- >> From: Julien Grall >> Sent: 2021年8月20日 19:24 >> To: Wei Chen ; xen-devel@lists.xenproject.org; >> sstabellini@kernel.org >> Cc: Bertrand Marquis >> Subject: Re: [XEN RFC PATCH 07/40] xen/arm: use !CONFIG_NUMA to keep fake >> NUMA API >> >> >> >> On 20/08/2021 11:24, Wei Chen wrote: >>> Hi Julien, >> >> Hi Wei, >> >>> >>>> -----Original Message----- >>>> From: Julien Grall >>>> Sent: 2021年8月20日 16:24 >>>> To: Wei Chen ; xen-devel@lists.xenproject.org; >>>> sstabellini@kernel.org; jbeulich@suse.com >>>> Cc: Bertrand Marquis >>>> Subject: Re: [XEN RFC PATCH 07/40] xen/arm: use !CONFIG_NUMA to keep >> fake >>>> NUMA API >>>> >>>> >>>> >>>> On 20/08/2021 03:08, Wei Chen wrote: >>>>> Hi Julien, >>>> >>>> Hi Wei, >>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Julien Grall >>>>>> Sent: 2021年8月19日 21:34 >>>>>> To: Wei Chen ; xen-devel@lists.xenproject.org; >>>>>> sstabellini@kernel.org; jbeulich@suse.com >>>>>> Cc: Bertrand Marquis >>>>>> Subject: Re: [XEN RFC PATCH 07/40] xen/arm: use !CONFIG_NUMA to keep >>>> fake >>>>>> NUMA API >>>>>> >>>>>> Hi Wei, >>>>>> >>>>>> On 11/08/2021 11:23, Wei Chen wrote: >>>>>>> Only Arm64 supports NUMA, the CONFIG_NUMA could not be >>>>>>> enabled for Arm32. >>>>>> >>>>>> What do you mean by "could not be enabled"? >>>>> >>>>> I have not seen any Arm32 hardware support NUMA, so I think >>>>> we don't need to support Arm32 NUMA. >>>> >>>> I understand that there may not be 32-bit platform with NUMA. And >> that's >>>> fine stating that in the commit message. However... >>>> >>>>> In this case, this Kconfig >>>>> option could not be enabled on Arm32. >>>> >>>> ... you continue to say "couldn't be enabled" without clarifying >> whether >>>> this mean that the build will break or this was just not tested because >>>> you don't have any platform. >>> >>> Ok, I understand your concern. Yes, my words would lead to mis- >> understanding. >>> If we make CONFIG_NUMA enabled in Arm32, it need Arm32 to implement some >>> code to support NUMA common code. Otherwise the Arm32 build will failed. >> >> When I skimmed through the series, most of the code seems to be either >> in common, arm (bitness neutral). So I am not quite too sure why it >> would not build. Do you have more details? >> > > It could not build because I have not tried to enable device_tree_numa > option for Arm32 but enabled NUMA for arm32. > > I have tested it again, yes, simple enable device_tree_numa and NUMA > for arm32 can build a image successfully. > > So, I think it's OK to enable this on Arm32, and I will do it in next > version. But, can we still keep these FAKE APIs? If user don't want to > enable NUMA they still can make Xen work? Yes, we still need to keep the FAKE APIs. I was only commenting about the wording in the commit message. > And I will remove "could not > enable for Arm32" from commit log. > >>> I have not tried to implement those code for Arm32. And I found there is >>> no Arm32 machine support NUMA, so I wanted Arm32 to use fake NUMA API >>> as before. >>> >>>> >>>> To put it differently, the code for NUMA looks bitness neutral. So I >>>> cannot really what what prevent us to potentially use it on Arm 32-bit. >>>> >>> >>> Yes, you're right, it's neutral. But do we really need to add code to an >>> ARCH that it may never use? >> >> Technically you already added the code because arch/arm/ is common >> between arm32 and arm64. My only ask is to not make the new config >> depends on arm64. If you only build test it that fine because... >> >> And how can we test this code? >> >> I don't expect any of the code to be an issue on arm32 as the code >> should mostly be arch neutral. > > I mean, we don't have Arm32 NUMA machine to test, I don't know > the code works well on Arm32 NUMA or not. I only can verify them > on non-NUMA arm32, and make sure this code will not break existed > machines. I understood you don't have any Arm32 NUMA machine. But I don't see the lack of testing as an issue because the code doesn't look to contain bits that may rely on arm64. So there are very limited reasons for the code to break on arm32. If we really want to test it, then it should be feasible to fake the NUMA node in the DT. However, I don't expect you to do it. Cheers, -- Julien Grall