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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73AC6C433F5 for ; Fri, 24 Sep 2021 19:34:18 +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 2702E60F9C for ; Fri, 24 Sep 2021 19:34:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2702E60F9C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.195600.348365 (Exim 4.92) (envelope-from ) id 1mTqxG-0000Ot-E1; Fri, 24 Sep 2021 19:33:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 195600.348365; Fri, 24 Sep 2021 19:33:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mTqxG-0000Om-B8; Fri, 24 Sep 2021 19:33:54 +0000 Received: by outflank-mailman (input) for mailman id 195600; Fri, 24 Sep 2021 19:33:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mTqxF-0000Og-8F for xen-devel@lists.xenproject.org; Fri, 24 Sep 2021 19:33:53 +0000 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b54de261-7f0e-487f-8cea-2c8eee6516b0; Fri, 24 Sep 2021 19:33:52 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 1E35661164; Fri, 24 Sep 2021 19:33:51 +0000 (UTC) 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: b54de261-7f0e-487f-8cea-2c8eee6516b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632512031; bh=3ikA21jUfX+27vnyX9raytkHozwFnL1Vzbqobe6Vmvg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=HSZNcDrcACykuSPV9IpsIPnvlFgAPUipXZ+BrtzpIuFEaoe2mQjKb8abORy/k9XUW OrOCUkuHJwcUYkQo0Nu4O7rgX1rKgCbS810G88TioUjxF33OFxaK8ndEuak8ywAUuY v5EkyPJRZ+OPynH79QWgjseZ8sdwSqb+eZIxdMchcYWLdmo7RP4pyPY1N2v2LfNi4k s52rXfJCT7LyHb8ls0hnRTzYXYGc2ilSLRz/+AmcKpF+mURIwawqOzy5in8bHpm86Z ZfY/sYSRgwfQpmkagqSXkRsynJGt8OHhVL8LOAJdAjGCwOktnI6kwvO1WQUdPuZEvC JIdHJAwErevWw== Date: Fri, 24 Sep 2021 12:33:50 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Jan Beulich cc: Stefano Stabellini , Wei Chen , xen-devel@lists.xenproject.org, julien@xen.org, Bertrand.Marquis@arm.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org Subject: Re: [PATCH 25/37] xen/arm: implement bad_srat for Arm NUMA initialization In-Reply-To: Message-ID: References: <20210923120236.3692135-1-wei.chen@arm.com> <20210923120236.3692135-26-wei.chen@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 24 Sep 2021, Jan Beulich wrote: > On 24.09.2021 04:09, Stefano Stabellini wrote: > > On Thu, 23 Sep 2021, Wei Chen wrote: > >> NUMA initialization will parse information from firmware provided > >> static resource affinity table (ACPI SRAT or DTB). bad_srat if a > >> function that will be used when initialization code encounters > >> some unexcepted errors. > >> > >> In this patch, we introduce Arm version bad_srat for NUMA common > >> initialization code to invoke it. > >> > >> Signed-off-by: Wei Chen > >> --- > >> xen/arch/arm/numa.c | 7 +++++++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c > >> index 3755b01ef4..5209d3de4d 100644 > >> --- a/xen/arch/arm/numa.c > >> +++ b/xen/arch/arm/numa.c > >> @@ -18,6 +18,7 @@ > >> * > >> */ > >> #include > >> +#include > >> #include > >> > >> static uint8_t __read_mostly > >> @@ -25,6 +26,12 @@ node_distance_map[MAX_NUMNODES][MAX_NUMNODES] = { > >> { 0 } > >> }; > >> > >> +__init void bad_srat(void) > >> +{ > >> + printk(KERN_ERR "NUMA: Firmware SRAT table not used.\n"); > >> + fw_numa = -1; > >> +} > > > > I realize that the series keeps the "srat" terminology everywhere on DT > > too. I wonder if it is worth replacing srat with something like > > "numa_distance" everywhere as appropriate. I am adding the x86 > > maintainers for an opinion. > > > > If you guys prefer to keep srat (if nothing else, it is concise), I am > > also OK with keeping srat although it is not technically accurate. > > I think we want to tell apart both things: Where we truly talk about > the firmware's SRAT table, keeping that name is fine. But I suppose > there no "Firmware SRAT table" (as in the log message above) when > using DT? No. FYI this is the DT binding: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/numa.txt The interesting bit is the "distance-map" > If so, at the very least in log messages SRAT shouldn't be > mentioned. Perhaps even functions serving both an ACPI and a DT > purpose would better not use "srat" in their names (but I'm not as > fussed about it there.) I agree 100% with what you wrote.