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=-10.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 2FC1BC433E1 for ; Sat, 18 Jul 2020 05:15:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ED7B52083E for ; Sat, 18 Jul 2020 05:15:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED7B52083E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hisilicon.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 29EE26B0080; Sat, 18 Jul 2020 01:15:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24EF76B0082; Sat, 18 Jul 2020 01:15:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13E318D0001; Sat, 18 Jul 2020 01:15:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id F32636B0080 for ; Sat, 18 Jul 2020 01:15:02 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3916A8248D7C for ; Sat, 18 Jul 2020 05:15:02 +0000 (UTC) X-FDA: 77050032444.27.ice09_3a0bf7a26f10 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id F30E727520 for ; Sat, 18 Jul 2020 05:15:01 +0000 (UTC) X-HE-Tag: ice09_3a0bf7a26f10 X-Filterd-Recvd-Size: 7745 Received: from huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Sat, 18 Jul 2020 05:14:59 +0000 (UTC) Received: from dggemi403-hub.china.huawei.com (unknown [172.30.72.53]) by Forcepoint Email with ESMTP id 0D419536A3432E45319E; Sat, 18 Jul 2020 13:14:54 +0800 (CST) Received: from DGGEMI525-MBS.china.huawei.com ([169.254.6.52]) by dggemi403-hub.china.huawei.com ([10.3.17.136]) with mapi id 14.03.0487.000; Sat, 18 Jul 2020 13:14:46 +0800 From: "Song Bao Hua (Barry Song)" To: Jonathan Cameron , "linux-mm@kvack.org" , "linux-acpi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "x86@kernel.org" CC: Lorenzo Pieralisi , Bjorn Helgaas , "linux-pci@vger.kernel.org" , "martin@geanix.com" , "Ingo Molnar" , "linux-ia64@vger.kernel.org" , Tony Luck , Fenghua Yu , Thomas Gleixner , Linuxarm , Dan Williams Subject: RE: [PATCH v2 2/6] ACPI: Do not create new NUMA domains from ACPI static tables that are not SRAT Thread-Topic: [PATCH v2 2/6] ACPI: Do not create new NUMA domains from ACPI static tables that are not SRAT Thread-Index: AQHWXGRWjNYnvk5OaEK31DY9SqiPZakMyeVA Date: Sat, 18 Jul 2020 05:14:46 +0000 Message-ID: References: <20200717175959.899775-1-Jonathan.Cameron@huawei.com> <20200717175959.899775-3-Jonathan.Cameron@huawei.com> In-Reply-To: <20200717175959.899775-3-Jonathan.Cameron@huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.200.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: F30E727520 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: > -----Original Message----- > From: Jonathan Cameron > Sent: Saturday, July 18, 2020 6:00 AM > To: linux-mm@kvack.org; linux-acpi@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; x86@kernel.org > Cc: Lorenzo Pieralisi ; Bjorn Helgaas > ; linux-pci@vger.kernel.org; martin@geanix.com; Ingo > Molnar ; linux-ia64@vger.kernel.org; Tony Luck > ; Fenghua Yu ; Thomas > Gleixner ; Linuxarm ; Dan > Williams ; Song Bao Hua (Barry Song) > ; Jonathan Cameron > > Subject: [PATCH v2 2/6] ACPI: Do not create new NUMA domains from ACPI > static tables that are not SRAT >=20 > Several ACPI static tables contain references to proximity domains. > ACPI 6.3 has clarified that only entries in SRAT may define a new domain > (sec 5.2.16). >=20 > Those tables described in the ACPI spec have additional clarifying text. >=20 > NFIT: Table 5-132, >=20 > "Integer that represents the proximity domain to which the memory belongs= . > This number must match with corresponding entry in the SRAT table." >=20 > HMAT: Table 5-145, >=20 > "... This number must match with the corresponding entry in the SRAT > table's processor affinity structure ... if the initiator is a processor= , > or the Generic Initiator Affinity Structure if the initiator is a generi= c > initiator". >=20 > IORT and DMAR are defined by external specifications. >=20 > Intel Virtualization Technology for Directed I/O Rev 3.1 does not make an= y > explicit statements, but the general SRAT statement above will still appl= y. > https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-= io-s > pec.pdf >=20 > IO Remapping Table, Platform Design Document rev D, also makes not explic= it > statement, but refers to ACPI SRAT table for more information and again t= he > generic SRAT statement above applies. > https://developer.arm.com/documentation/den0049/d/ >=20 > In conclusion, any proximity domain specified in these tables, should be = a > reference to a proximity domain also found in SRAT, and they should not b= e > able > to instantiate a new domain. Hence we switch to pxm_to_node() which will > only > return existing nodes. >=20 > Signed-off-by: Jonathan Cameron Much better than v1 which was using a bool parameter "false" to stop acpi_m= ap_pxm_to_node() from creating node. And pxm_to_node() has been used by some other places as an API which is serving the transition from pxm to node. Reviewed-by: Barry Song > --- > drivers/acpi/arm64/iort.c | 2 +- > drivers/acpi/nfit/core.c | 3 +-- > drivers/acpi/numa/hmat.c | 2 +- > drivers/iommu/intel/dmar.c | 2 +- > 4 files changed, 4 insertions(+), 5 deletions(-) >=20 > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > index 28a6b387e80e..eb0f158612c8 100644 > --- a/drivers/acpi/arm64/iort.c > +++ b/drivers/acpi/arm64/iort.c > @@ -1293,7 +1293,7 @@ static int __init > arm_smmu_v3_set_proximity(struct device *dev, >=20 > smmu =3D (struct acpi_iort_smmu_v3 *)node->node_data; > if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) { > - int dev_node =3D acpi_map_pxm_to_node(smmu->pxm); > + int dev_node =3D pxm_to_node(smmu->pxm); >=20 > if (dev_node !=3D NUMA_NO_NODE && !node_online(dev_node)) > return -EINVAL; > diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c > index 7c138a4edc03..d933a4636d00 100644 > --- a/drivers/acpi/nfit/core.c > +++ b/drivers/acpi/nfit/core.c > @@ -2947,8 +2947,7 @@ static int acpi_nfit_register_region(struct > acpi_nfit_desc *acpi_desc, > if (spa->flags & ACPI_NFIT_PROXIMITY_VALID) { > ndr_desc->numa_node =3D acpi_map_pxm_to_online_node( > spa->proximity_domain); > - ndr_desc->target_node =3D acpi_map_pxm_to_node( > - spa->proximity_domain); > + ndr_desc->target_node =3D pxm_to_node(spa->proximity_domain); > } else { > ndr_desc->numa_node =3D NUMA_NO_NODE; > ndr_desc->target_node =3D NUMA_NO_NODE; > diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c > index 2c32cfb72370..cf6df2df26cd 100644 > --- a/drivers/acpi/numa/hmat.c > +++ b/drivers/acpi/numa/hmat.c > @@ -666,7 +666,7 @@ static void hmat_register_target_device(struct > memory_target *target, >=20 > pdev->dev.numa_node =3D > acpi_map_pxm_to_online_node(target->memory_pxm); > info =3D (struct memregion_info) { > - .target_node =3D acpi_map_pxm_to_node(target->memory_pxm), > + .target_node =3D pxm_to_node(target->memory_pxm), > }; > rc =3D platform_device_add_data(pdev, &info, sizeof(info)); > if (rc < 0) { > diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c > index 683b812c5c47..b1acdaead059 100644 > --- a/drivers/iommu/intel/dmar.c > +++ b/drivers/iommu/intel/dmar.c > @@ -473,7 +473,7 @@ static int dmar_parse_one_rhsa(struct > acpi_dmar_header *header, void *arg) > rhsa =3D (struct acpi_dmar_rhsa *)header; > for_each_drhd_unit(drhd) { > if (drhd->reg_base_addr =3D=3D rhsa->base_address) { > - int node =3D acpi_map_pxm_to_node(rhsa->proximity_domain); > + int node =3D pxm_to_node(rhsa->proximity_domain); >=20 > if (!node_online(node)) > node =3D NUMA_NO_NODE; > -- > 2.19.1 Thanks Barry