From patchwork Wed Jul 26 10:15:49 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hanjun Guo X-Patchwork-Id: 108751 Delivered-To: patch@linaro.org Received: by 10.182.45.195 with SMTP id p3csp645776obm; Wed, 26 Jul 2017 03:23:04 -0700 (PDT) X-Received: by 10.99.104.3 with SMTP id d3mr423342pgc.278.1501064583952; Wed, 26 Jul 2017 03:23:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501064583; cv=none; d=google.com; s=arc-20160816; b=sH/bUf3qyg2Pa8D+Hvg3pc0t0ycdj3BK6BE7xn+bxUFZC+1JSYfWYDtKFPWiji5rMm OVXGwUyFmxSoFAqFPGXwtztkTBWyl1RO7xmdGjTj5+QbQLXgVbOOZMOXaZZanHxPk1VJ TvVZ8bdp09B4gHlF8g2pSDINXFM9BFq4cSHRoyOv5MVdZnVy+48gyX1QdZUXD6JoxHoN NQTDWsRggHAZlJYm2uCpcyCTnEt3ZMg9irBuAOWYkR5JiXUui6lBHWWXEQVFJqAl6har I8CnXND0LFp6K9pxhsKo3Laajr6izFgZaul54qElLGSXVS0O1kJjaA2J1RzZ6ha/wVcj o0rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=sOlXbjSq6DQW/ea7wsm2t9OGIVjGqHk+A9Ktv5u91Xo=; b=NkkbqNemBmfdspcsLu8vdW0Is39vhpZvFrjm/S9ISqW+LyiXRLJJLoByfGHic+3ppR q5IGAoPk3MKHPuPKMBciFKDhDHdvx2eEyTO69tPvAcEK1tO1Yl2QPE6yuiEFCNxbIt2L s6mAMR5Ut0DB3bHM7kvP2MWBhXoap0Ha5TiiJ/iUs1biAk4QBuFZQgjiaa9Hsi8r65Vz 4AJgTWj4rcMX31ssnB8OYrLfcYL4PsLRglJjs0oCwufxpXeUSvPC0riK4juY40xkKQeD Su+jSLFMbyqVUKFXAzP6NJ2ennMMTGr/lV1J80/JaKgzQiOs7hSmzh/Y1fExtP5DO2yF TbTQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u65si9308177pfa.644.2017.07.26.03.23.03; Wed, 26 Jul 2017 03:23:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751573AbdGZKXC (ORCPT + 7 others); Wed, 26 Jul 2017 06:23:02 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:9424 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751472AbdGZKXC (ORCPT ); Wed, 26 Jul 2017 06:23:02 -0400 Received: from 172.30.72.57 (EHLO DGGEML404-HUB.china.huawei.com) ([172.30.72.57]) by dggrg03-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id ASD01438; Wed, 26 Jul 2017 18:22:39 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEML404-HUB.china.huawei.com (10.3.17.39) with Microsoft SMTP Server id 14.3.301.0; Wed, 26 Jul 2017 18:22:31 +0800 From: Hanjun Guo To: Thomas Gleixner , Marc Zyngier CC: , , , , Hanjun Guo , Ganapatrao Kulkarni , John Garry Subject: [PATCH v3] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES Date: Wed, 26 Jul 2017 18:15:49 +0800 Message-ID: <1501064149-37285-1-git-send-email-guohanjun@huawei.com> X-Mailer: git-send-email 1.7.12.4 MIME-Version: 1.0 X-Originating-IP: [10.175.102.37] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59786D70.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bcf23f7a959cf0c8b7f487efc8bb18be Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org From: Hanjun Guo When enabling ITS NUMA support on D05, I got the boot log: [ 0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0 [ 0.000000] SRAT: PXM 0 -> ITS 1 -> Node 0 [ 0.000000] SRAT: PXM 0 -> ITS 2 -> Node 0 [ 0.000000] SRAT: PXM 1 -> ITS 3 -> Node 1 [ 0.000000] SRAT: ITS affinity exceeding max count[4] This is wrong on D05 as we have 8 ITSs with 4 NUMA nodes. So dynamically alloc the memory needed instead of using its_srat_maps[MAX_NUMNODES], which count the number of ITS entry(ies) in SRAT and alloc its_srat_maps as needed, then build the mapping of numa node to ITS ID. Of course, its_srat_maps will be freed after ITS probing because we don't need that after boot. After doing this, I got what I wanted: [ 0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0 [ 0.000000] SRAT: PXM 0 -> ITS 1 -> Node 0 [ 0.000000] SRAT: PXM 0 -> ITS 2 -> Node 0 [ 0.000000] SRAT: PXM 1 -> ITS 3 -> Node 1 [ 0.000000] SRAT: PXM 2 -> ITS 4 -> Node 2 [ 0.000000] SRAT: PXM 2 -> ITS 5 -> Node 2 [ 0.000000] SRAT: PXM 2 -> ITS 6 -> Node 2 [ 0.000000] SRAT: PXM 3 -> ITS 7 -> Node 3 Fixes: dbd2b8267233 ("irqchip/gic-v3-its: Add ACPI NUMA node mapping") Signed-off-by: Hanjun Guo Reviewed-by: Lorenzo Pieralisi Cc: Ganapatrao Kulkarni Cc: John Garry Cc: Marc Zyngier --- v2->v3: - Remove the NULL check for its_srat_maps as its_in_srat will be 0; - Add warning if alloc memory failed for its_srat_maps; - Update commit log as Lorenzo suggested; - Add review tag drivers/irqchip/irq-gic-v3-its.c | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-) -- 1.7.12.4 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 3ccdf76..bf70115 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1847,7 +1847,7 @@ struct its_srat_map { u32 its_id; }; -static struct its_srat_map its_srat_maps[MAX_NUMNODES] __initdata; +static struct its_srat_map *its_srat_maps __initdata; static int its_in_srat __initdata; static int __init acpi_get_its_numa_node(u32 its_id) @@ -1861,6 +1861,12 @@ static int __init acpi_get_its_numa_node(u32 its_id) return NUMA_NO_NODE; } +static int __init gic_acpi_match_srat_its(struct acpi_subtable_header *header, + const unsigned long end) +{ + return 0; +} + static int __init gic_acpi_parse_srat_its(struct acpi_subtable_header *header, const unsigned long end) { @@ -1877,12 +1883,6 @@ static int __init gic_acpi_parse_srat_its(struct acpi_subtable_header *header, return -EINVAL; } - if (its_in_srat >= MAX_NUMNODES) { - pr_err("SRAT: ITS affinity exceeding max count[%d]\n", - MAX_NUMNODES); - return -EINVAL; - } - node = acpi_map_pxm_to_node(its_affinity->proximity_domain); if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) { @@ -1901,14 +1901,37 @@ static int __init gic_acpi_parse_srat_its(struct acpi_subtable_header *header, static void __init acpi_table_parse_srat_its(void) { + int count; + + count = acpi_table_parse_entries(ACPI_SIG_SRAT, + sizeof(struct acpi_table_srat), + ACPI_SRAT_TYPE_GIC_ITS_AFFINITY, + gic_acpi_match_srat_its, 0); + if (count <= 0) + return; + + its_srat_maps = kmalloc(count * sizeof(struct its_srat_map), + GFP_KERNEL); + if (!its_srat_maps) { + pr_warn("SRAT: Failed to allocate memory for its_srat_maps!\n"); + return; + } + acpi_table_parse_entries(ACPI_SIG_SRAT, sizeof(struct acpi_table_srat), ACPI_SRAT_TYPE_GIC_ITS_AFFINITY, gic_acpi_parse_srat_its, 0); } + +/* free the its_srat_maps after ITS probing */ +static void __init acpi_its_srat_maps_free(void) +{ + kfree(its_srat_maps); +} #else static void __init acpi_table_parse_srat_its(void) { } static int __init acpi_get_its_numa_node(u32 its_id) { return NUMA_NO_NODE; } +static void __init acpi_its_srat_maps_free(void) { } #endif static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header, @@ -1955,6 +1978,7 @@ static void __init its_acpi_probe(void) acpi_table_parse_srat_its(); acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR, gic_acpi_parse_madt_its, 0); + acpi_its_srat_maps_free(); } #else static void __init its_acpi_probe(void) { }