From patchwork Fri Jul 17 17:59:59 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Cameron X-Patchwork-Id: 235744 Delivered-To: patch@linaro.org Received: by 2002:a92:d244:0:0:0:0:0 with SMTP id v4csp1928246ilg; Fri, 17 Jul 2020 11:03:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxYemAqfR95aT+MDE64/9yh1tk7rA99XUvHt7kC/Q92UyOcKqmogzlLh32ZLeVd/EOUmfM0 X-Received: by 2002:aa7:d814:: with SMTP id v20mr10421642edq.296.1595009029302; Fri, 17 Jul 2020 11:03:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595009029; cv=none; d=google.com; s=arc-20160816; b=Sr63KEytyn1CaU2AvKZODuWQxZe63GmEY6Aa4u1lNZJAfIVVSqc5t32BQYZnnrykSM Pjpo3urmjBUGjeEjZcbXxdUqS0lPoiCaPNaugTTcODmCJdsuEMdUL2HLsGsx8V4zWb6q RoF0b5ZP8sYLbJhMEVe9apWOnyq2s6W5c1ME0SwYI1ldVFiU+RYGpLX3xKchRkPYcsg8 k5Zb7ThApgV5+JVjBbJYg2c/tB81YCImhw2Ob3NyA6FJCxcHmlZ1ovsRQ0X4VG7lOsrG tDZy0ZXeN5zh9khZhEke5nhE4T8SCJRZvSCRcZZ8TtPMX9aRgzsJQrIlCxzslgULyc7S Kqow== 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=slSNqozzYlxnFMwWUQhHExotzCJSBovPo0SgCzsdQ4Q=; b=gw7a46IANCCF5LmcqHNaOz/LI2uuZcCmd3czPGf3buAERB8g8+6/wQsvqJYAv7wULP 4xJRaHhtXYOJckjyPvPbSUtc8yRZVWmpx/VyDb06MJOyZm3ZKS0b5M8EeIAN+yJrcbUY 7z/MiUoRxqyjpRNNgMmkVjr2VkQ50oHNUhFo/XRB+i+iBq3Zj8m5egui8fG4LdJ5fG2I ajFfilV0z1Qp66Fr3gERly6zidDm3Omm3WwOnMR4V7j4qxW66okXfKESe+qU2ZDtX9dN oTISTAdnGEMxW7ZDMaYIvNyYOiOMPtNOTLjfiZqfd3q8uJl3q/vGc9QoUOqJBE2s5Jtz nVGw== 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 i25si5851231edr.503.2020.07.17.11.03.49; Fri, 17 Jul 2020 11:03:49 -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 S1726670AbgGQSDs (ORCPT + 7 others); Fri, 17 Jul 2020 14:03:48 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2503 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727903AbgGQSDs (ORCPT ); Fri, 17 Jul 2020 14:03:48 -0400 Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BB0A8F4BF11DF7754B29; Fri, 17 Jul 2020 19:03:46 +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_CBC_SHA256) id 15.1.1913.5; Fri, 17 Jul 2020 19:03:46 +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 v2 6/6] irq-chip/gic-v3-its: Fix crash if ITS is in a proximity domain without processor or memory Date: Sat, 18 Jul 2020 01:59:59 +0800 Message-ID: <20200717175959.899775-7-Jonathan.Cameron@huawei.com> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20200717175959.899775-1-Jonathan.Cameron@huawei.com> References: <20200717175959.899775-1-Jonathan.Cameron@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.123.41.22] X-ClientProxiedBy: lhreml706-chm.china.huawei.com (10.201.108.55) 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 Note this crash is present before any of the patches in this series, but as explained below it is highly unlikely anyone is shipping a firmware that causes it. Tests were done using an overriden SRAT. On ARM64, the gic-v3 driver directly parses SRAT to locate GIC Interrupt Translation Service (ITS) Affinity Structures. This is done much later in the boot than the parses of SRAT which identify proximity domains. As a result, an ITS placed in a proximity domain that is not defined by another SRAT structure will result in a NUMA node that is not completely configured and a crash. ITS [mem 0x202100000-0x20211ffff] ITS@0x0000000202100000: Using ITS number 0 Unable to handle kernel paging request at virtual address 0000000000001a08 ... Call trace: __alloc_pages_nodemask+0xe8/0x338 alloc_pages_node.constprop.0+0x34/0x40 its_probe_one+0x2f8/0xb18 gic_acpi_parse_madt_its+0x108/0x150 acpi_table_parse_entries_array+0x17c/0x264 acpi_table_parse_entries+0x48/0x6c acpi_table_parse_madt+0x30/0x3c its_init+0x1c4/0x644 gic_init_bases+0x4b8/0x4ec gic_acpi_init+0x134/0x264 acpi_match_madt+0x4c/0x84 acpi_table_parse_entries_array+0x17c/0x264 acpi_table_parse_entries+0x48/0x6c acpi_table_parse_madt+0x30/0x3c __acpi_probe_device_table+0x8c/0xe8 irqchip_init+0x3c/0x48 init_IRQ+0xcc/0x100 start_kernel+0x33c/0x548 ACPI 6.3 allows any set of Affinity Structures in SRAT to define a proximity domain. However, as we do not see this crash, we can conclude that no firmware is currently placing an ITS in a node that is separate from those containing memory and / or processors. We could modify the SRAT parsing behavior to identify the existence of Proximity Domains unique to the ITS structures, and handle them as a special case of a generic initiator (once support for those merges). This patch avoids the complexity that would be needed to handle this corner case, by not allowing the ITS entry parsing code to instantiate new NUMA Nodes. If one is encountered that does not already exist, then NO_NUMA_NODE is assigned and a warning printed just as if the value had been greater than allowed NUMA Nodes. "SRAT: Invalid NUMA node -1 in ITS affinity" Whilst this does not provide the full flexibility allowed by ACPI, it does fix the problem. We can revisit a more sophisticated solution if needed by future platforms. Change is simply to replace acpi_map_pxm_to_node with pxm_to_node reflecting the fact a new mapping is not created. Signed-off-by: Jonathan Cameron --- drivers/irqchip/irq-gic-v3-its.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) -- 2.19.1 diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 6a5a87fc4601..c26862a074da 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -5248,7 +5248,12 @@ static int __init gic_acpi_parse_srat_its(union acpi_subtable_headers *header, return -EINVAL; } - node = acpi_map_pxm_to_node(its_affinity->proximity_domain); + /* + * Note that in theory a new proximity node could be created by this + * entry as it is an SRAT resource allocation structure. + * We do not currently support doing so. + */ + node = pxm_to_node(its_affinity->proximity_domain); if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) { pr_err("SRAT: Invalid NUMA node %d in ITS affinity\n", node);