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 1BE01C4338F for ; Fri, 20 Aug 2021 11:24:45 +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 D90EA60EBD for ; Fri, 20 Aug 2021 11:24:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D90EA60EBD 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.169437.309514 (Exim 4.92) (envelope-from ) id 1mH2dT-0000yK-Kg; Fri, 20 Aug 2021 11:24:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 169437.309514; Fri, 20 Aug 2021 11:24:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mH2dT-0000yD-HV; Fri, 20 Aug 2021 11:24:31 +0000 Received: by outflank-mailman (input) for mailman id 169437; Fri, 20 Aug 2021 11:24:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mH2dR-0000y3-V4 for xen-devel@lists.xenproject.org; Fri, 20 Aug 2021 11:24:29 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mH2dR-0000Zg-QG; Fri, 20 Aug 2021 11:24:29 +0000 Received: from [54.239.6.178] (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 1mH2dR-0006o0-KE; Fri, 20 Aug 2021 11:24:29 +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=ll30wo+4e6oD6mjhRlwn499a0z9259KKTu5M4AJtpqw=; b=MOgD+EO+Ny57urievkEmFBaJkS mVaHgdKn+vJJux1nS3pD3aGkLq0h6P15ppB1PtxcWUnJygEBskzGExUDnPrdnNac6JLf9ga46XdMN 7wmZvxHQt8oMrS8tJgaOvsU9MGBDwAB+/ZTdX5qXwUTatU/qDpWCbPIOMdrG288mTYAM=; 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> From: Julien Grall Message-ID: <54707c92-3bda-60b8-4b36-1eae172cacb1@xen.org> Date: Fri, 20 Aug 2021 12:24:28 +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 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? > 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. Cheers, -- Julien Grall