From patchwork Tue Aug 18 14:24:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Cameron X-Patchwork-Id: 247892 Delivered-To: patch@linaro.org Received: by 2002:a54:3b12:0:0:0:0:0 with SMTP id j18csp3177955ect; Tue, 18 Aug 2020 07:26:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1yIbKi86/gb2MxB0AKCatZEZL5W6GP+DdVvEimwXM2jYMhHGfpSUHZ2J2hMxQWx/rDE/X X-Received: by 2002:a17:906:c143:: with SMTP id dp3mr20006721ejc.504.1597760783370; Tue, 18 Aug 2020 07:26:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597760783; cv=none; d=google.com; s=arc-20160816; b=p2g4yB0PyxAeTg61bDmxHqs3R8uvGGXeKlKdNRloOsyz2OOD2/6yn/VF+30qGpdbt0 fnV+/iqkJPU34N2o/M4CZ730rjOiUbJVaF4c9AbreRMHePOx1Ti7zxkq0AixlXnDqbxy 2G1wcV32DxPPfx9gB2W1ITvUPNaBa6X+zM35mKT6IFEu0q1IiV60/nTR/A/5jvuZFWEh 5TOOAuVGK0jFf0tf+w4TFdptlnPTMOCV30xr3QY9LOzChKcYGrgrUlEKvtrOYcPXi/Cl oEtCCJ4Sbz+05NkDZpfgB9LI37UbtkS5q9LgxII0A897RrUJcx8AwcgiHBM3GQlHhhbg /Llg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=HHKb4KD8XrTyfaqrZpNeO8sVUSaJ2cxtb8GqKKG6YPE=; b=Pqkn9ZdcigBPetFv2+fkAyIJ7cGBAK2pxpbfoyCDd4KU4kt3Vk2zyU2QoWdMnZN5JB MRA9JfZ78c5MSb97lbkjvQFokI0q2xEbbNE/qsbxAm9HbsZM7S/iBVTkW8fraecIp54T QlTd20sUXoQGe2YsyT1uuOKpvl86dGQPVUlzP49WGzQLh0FVo1ELodkC8DgwlKCI2iB4 U0HLV+3qUUVP1u1A2Z+0F7tY0ts3p7qRHe0srXsN7MGLKaZv4wO28ALObm2hxsmsJwGq 9Yfy/YSjHIuXLekAmoU6m5VBO4LbnY/PPq3AJU5ghQMNaQoau6tlkZYwkzZWveDu0jF7 wfPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-acpi-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dd10si1385168ejb.100.2020.08.18.07.26.23; Tue, 18 Aug 2020 07:26:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-acpi-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-acpi-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726904AbgHRO0V (ORCPT + 7 others); Tue, 18 Aug 2020 10:26:21 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2618 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727023AbgHRO0H (ORCPT ); Tue, 18 Aug 2020 10:26:07 -0400 Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 54371C421462139A9821; Tue, 18 Aug 2020 15:26:06 +0100 (IST) Received: from lhrphicprd00229.huawei.com (10.123.41.22) 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; Tue, 18 Aug 2020 15:26:06 +0100 From: Jonathan Cameron To: , , , CC: Lorenzo Pieralisi , Bjorn Helgaas , , , Ingo Molnar , , Tony Luck , Fenghua Yu , Thomas Gleixner , , Dan Williams , Song Bao Hua , Jonathan Cameron Subject: [PATCH v3 2/6] ACPI: Do not create new NUMA domains from ACPI static tables that are not SRAT Date: Tue, 18 Aug 2020 22:24:26 +0800 Message-ID: <20200818142430.1156547-3-Jonathan.Cameron@huawei.com> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20200818142430.1156547-1-Jonathan.Cameron@huawei.com> References: <20200818142430.1156547-1-Jonathan.Cameron@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.123.41.22] X-ClientProxiedBy: lhreml710-chm.china.huawei.com (10.201.108.61) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 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). Those tables described in the ACPI spec have additional clarifying text. NFIT: Table 5-132, "Integer that represents the proximity domain to which the memory belongs. This number must match with corresponding entry in the SRAT table." HMAT: Table 5-145, "... 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 generic initiator". IORT and DMAR are defined by external specifications. Intel Virtualization Technology for Directed I/O Rev 3.1 does not make any explicit statements, but the general SRAT statement above will still apply. https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf IO Remapping Table, Platform Design Document rev D, also makes not explicit statement, but refers to ACPI SRAT table for more information and again the generic SRAT statement above applies. https://developer.arm.com/documentation/den0049/d/ 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 be able to instantiate a new domain. Hence we switch to pxm_to_node() which will only return existing nodes. Signed-off-by: Jonathan Cameron Reviewed-by: Barry Song Reviewed-by: Hanjun Guo --- 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(-) -- 2.19.1 diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index ec782e4a0fe4..26005a15cb8b 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -1335,7 +1335,7 @@ static int __init arm_smmu_v3_set_proximity(struct device *dev, smmu = (struct acpi_iort_smmu_v3 *)node->node_data; if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) { - int dev_node = acpi_map_pxm_to_node(smmu->pxm); + int dev_node = pxm_to_node(smmu->pxm); if (dev_node != NUMA_NO_NODE && !node_online(dev_node)) return -EINVAL; diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c index 26dd208a0d63..ea0557cb54f7 100644 --- a/drivers/acpi/nfit/core.c +++ b/drivers/acpi/nfit/core.c @@ -3008,8 +3008,7 @@ static int acpi_nfit_register_region(struct acpi_nfit_desc *acpi_desc, if (spa->flags & ACPI_NFIT_PROXIMITY_VALID) { ndr_desc->numa_node = acpi_map_pxm_to_online_node( spa->proximity_domain); - ndr_desc->target_node = acpi_map_pxm_to_node( - spa->proximity_domain); + ndr_desc->target_node = pxm_to_node(spa->proximity_domain); } else { ndr_desc->numa_node = NUMA_NO_NODE; ndr_desc->target_node = 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, pdev->dev.numa_node = acpi_map_pxm_to_online_node(target->memory_pxm); info = (struct memregion_info) { - .target_node = acpi_map_pxm_to_node(target->memory_pxm), + .target_node = pxm_to_node(target->memory_pxm), }; rc = 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 93e6345f3414..2f3badd41e1b 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 = (struct acpi_dmar_rhsa *)header; for_each_drhd_unit(drhd) { if (drhd->reg_base_addr == rhsa->base_address) { - int node = acpi_map_pxm_to_node(rhsa->proximity_domain); + int node = pxm_to_node(rhsa->proximity_domain); if (!node_online(node)) node = NUMA_NO_NODE;