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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 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 20D4AC433E2 for ; Mon, 6 Jul 2020 10:47:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E49C02074D for ; Mon, 6 Jul 2020 10:47:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E49C02074D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=Huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6896E6B0003; Mon, 6 Jul 2020 06:47:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 612B06B0007; Mon, 6 Jul 2020 06:47:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DA736B000E; Mon, 6 Jul 2020 06:47:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id 352AA6B0003 for ; Mon, 6 Jul 2020 06:47:12 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AA808181AEF00 for ; Mon, 6 Jul 2020 10:47:11 +0000 (UTC) X-FDA: 77007323862.15.snow40_4f14c6326eab Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 7F0631814B0C8 for ; Mon, 6 Jul 2020 10:47:11 +0000 (UTC) X-HE-Tag: snow40_4f14c6326eab X-Filterd-Recvd-Size: 5394 Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Mon, 6 Jul 2020 10:47:10 +0000 (UTC) Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6BF1FF7319A1771C71D1; Mon, 6 Jul 2020 11:47:09 +0100 (IST) Received: from localhost (10.52.123.111) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 6 Jul 2020 11:47:08 +0100 Date: Mon, 6 Jul 2020 11:46:05 +0100 From: Jonathan Cameron To: Jia He CC: Catalin Marinas , Will Deacon , Andrew Morton , Mike Rapoport , Baoquan He , Chuhong Yuan , , , , Kaly Xin Subject: Re: [PATCH 1/3] arm64/numa: set numa_off to false when numa node is fake Message-ID: <20200706114605.000050ac@Huawei.com> In-Reply-To: <20200706112921.00006f7f@Huawei.com> References: <20200706011947.184166-1-justin.he@arm.com> <20200706011947.184166-2-justin.he@arm.com> <20200706112921.00006f7f@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.52.123.111] X-ClientProxiedBy: lhreml717-chm.china.huawei.com (10.201.108.68) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 7F0631814B0C8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 6 Jul 2020 11:29:21 +0100 Jonathan Cameron wrote: > On Mon, 6 Jul 2020 09:19:45 +0800 > Jia He wrote: > > Hi, > > > Previously, numa_off is set to true unconditionally in dummy_numa_init(), > > even if there is a fake numa node. > > > > But acpi will translate node id to NUMA_NO_NODE(-1) in acpi_map_pxm_to_node() > > because it regards numa_off as turning off the numa node. > > That is correct. It is operating exactly as it should, if SRAT hasn't been parsed > and you are on ACPI platform there are no nodes. They cannot be created at > some later date. The dummy code doesn't change this. It just does enough to carry > on operating with no specified nodes. > > > > > Without this patch, pmem can't be probed as a RAM device on arm64 if SRAT table > > isn't present. > > > > $ndctl create-namespace -fe namespace0.0 --mode=devdax --map=dev -s 1g -a 64K > > kmem dax0.0: rejecting DAX region [mem 0x240400000-0x2bfffffff] with invalid node: -1 > > kmem: probe of dax0.0 failed with error -22 > > > > This fixes it by setting numa_off to false. > > Without the SRAT protection patch [1] you may well run into problems > because someone somewhere will have _PXM in a DSDT but will > have a non existent SRAT. We had this happen on an AMD platform when we > tried to introduce working _PXM support for PCI. [2] > > So whilst this seems superficially safe, I'd definitely be crossing your fingers. > Note, at that time I proposed putting the numa_off = false into the x86 code > path precisely to cut out that possibility (was rejected at the time, at least > partly because the clarifications to the ACPI spec were not pubilc.) > > The patch in [1] should sort things out however by ensuring we only create > new domains where we should actually be doing so. However, in your case > it will return NUMA_NO_NODE anyway so this isn't the right way to fix things. > > [1] https://patchwork.kernel.org/patch/11632063/ > [2] https://patchwork.kernel.org/patch/10597777/ Thinking a bit more on this... I'd like to understand more on what your use case is. Do you have an NFIT that is setting the proximity domain for the non-volatile memory in SPA structures? If so the ACPI spec (6.3 makes this clear) requires those match with domains described in SRAT. If SRAT isn't there, then we can't expect sensible results from using these values from NFIT. If SRAT is there and numa=off is set then we should probably also rule out parsing NFIT, or make all nfit handling fine with NO_NUMA_NODE, preferably with explicit checks to ensure we don't try to use the Proximity Node values as they have no meaning with numa=off. I note that the core NFIT parsing is fine with the value not being supplied in the first place. https://elixir.bootlin.com/linux/latest/source/drivers/acpi/nfit/core.c#L2947 Thanks, Jonathan > > Thanks, > > Jonathan > > > > > Signed-off-by: Jia He > > --- > > arch/arm64/mm/numa.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c > > index aafcee3e3f7e..7689986020d9 100644 > > --- a/arch/arm64/mm/numa.c > > +++ b/arch/arm64/mm/numa.c > > @@ -440,7 +440,8 @@ static int __init dummy_numa_init(void) > > return ret; > > } > > > > - numa_off = true; > > + /* force numa_off to be false since we have a fake numa node here */ > > + numa_off = false; > > return 0; > > } > > >