From patchwork Mon Sep 27 06:41:18 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gavin Shan X-Patchwork-Id: 1533219 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ReIHAHt0; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by bilbo.ozlabs.org (Postfix) with ESMTP id 4HHtNp4bLQz9tkT for ; Mon, 27 Sep 2021 16:42:34 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233010AbhI0GoJ (ORCPT ); Mon, 27 Sep 2021 02:44:09 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:42819 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233001AbhI0GoI (ORCPT ); Mon, 27 Sep 2021 02:44:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632724950; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dgUQa1q2yVLHuH43oDCQpdzXKKAxjWaL6vBqtSCv00M=; b=ReIHAHt0MuirtnZLFJ+JLF6dsGVUXAKthJgB4ZIyuc/3LkhSicZnSQL1E4LPwfmU5u6C65 uGr3htfVuoY9ClojzWoDQPv9V+EoLleFSvl3eqPtq1IuKHhOpb764ZAC9Mbf+5HteGPuBa j3qHRWJFSpUgkW59Be6T288fb2ehtlA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-548-Up7L8uypM4ConrfU_bs3rA-1; Mon, 27 Sep 2021 02:42:28 -0400 X-MC-Unique: Up7L8uypM4ConrfU_bs3rA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 977BC1966320; Mon, 27 Sep 2021 06:42:26 +0000 (UTC) Received: from gshan.redhat.com (vpn2-54-16.bne.redhat.com [10.64.54.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9527560936; Mon, 27 Sep 2021 06:42:22 +0000 (UTC) From: Gavin Shan To: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, robh@kernel.org, maz@kernel.org, rdunlap@infradead.org, catalin.marinas@arm.com, will@kernel.org, shan.gavin@gmail.com Subject: [PATCH v2 1/2] Documentation, dt, numa: Add note to empty NUMA node Date: Mon, 27 Sep 2021 14:41:18 +0800 Message-Id: <20210927064119.127285-2-gshan@redhat.com> In-Reply-To: <20210927064119.127285-1-gshan@redhat.com> References: <20210927064119.127285-1-gshan@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org The empty memory nodes, where no memory resides in, are allowed. The NUMA node IDs are still valid and parsed, but memory may be added to them through hotplug afterwards. Currently, QEMU fails to boot when multiple empty memory nodes are specified. It's caused by device-tree population failure and duplicated memory node names. The device-tree specification doesn't provide how empty NUMA nodes are handled. Besides, I finds difficulty to get where this case is documented. So lets add a section for empty memory nodes to cover it in NUMA binding document. Signed-off-by: Gavin Shan --- Documentation/devicetree/bindings/numa.txt | 46 +++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt index 21b35053ca5a..42f282c2f3cc 100644 --- a/Documentation/devicetree/bindings/numa.txt +++ b/Documentation/devicetree/bindings/numa.txt @@ -103,7 +103,51 @@ Example: }; ============================================================================== -4 - Example dts +4 - Empty memory nodes +============================================================================== + +Empty memory nodes, which no memory resides in, are allowed. There are no +device nodes for these empty memory nodes. However, the NUMA node IDs and +distance maps are still valid and memory may be added into them through +hotplug afterwards. + +Example: + + memory@0 { + device_type = "memory"; + reg = <0x0 0x0 0x0 0x80000000>; + numa-node-id = <0>; + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x0 0x80000000 0x0 0x80000000>; + numa-node-id = <1>; + }; + + /* Empty memory node 2 and 3 */ + distance-map { + compatible = "numa-distance-map-v1"; + distance-matrix = <0 0 10>, + <0 1 20>, + <0 2 40>, + <0 3 20>, + <1 0 20>, + <1 1 10>, + <1 2 20>, + <1 3 40>, + <2 0 40>, + <2 1 20>, + <2 2 10>, + <2 3 20>, + <3 0 20>, + <3 1 40>, + <3 2 20>, + <3 3 10>; + }; + +============================================================================== +5 - Example dts ============================================================================== Dual socket system consists of 2 boards connected through ccn bus and From patchwork Mon Sep 27 06:41:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gavin Shan X-Patchwork-Id: 1533220 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=cKVgivoH; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by bilbo.ozlabs.org (Postfix) with ESMTP id 4HHtNw1wLjz9tkT for ; Mon, 27 Sep 2021 16:42:40 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233029AbhI0GoP (ORCPT ); Mon, 27 Sep 2021 02:44:15 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:55324 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233036AbhI0GoP (ORCPT ); Mon, 27 Sep 2021 02:44:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632724957; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A7XJHc0p1FnNm1Yats8TDvDF65ghYHfrSmniJKe3ULQ=; b=cKVgivoHRsvbr7xNufHfrbmieP7Uf7mHOSqf2UVpN1k9VoNlgHHX7UeWD3un8jIjiR5GEY gpuq3TN8Ba/ryZK4B8NnlsMRSOuNHJtnGJkO4pHV7KWHY1yP7pdx4Bp5Y1XLWlPq9GHEf9 v2cAnuhtzJshzJImY4S1MoeEMdDE1Kc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-313-T6Ky4i-5M0mFA2scRJonRQ-1; Mon, 27 Sep 2021 02:42:33 -0400 X-MC-Unique: T6Ky4i-5M0mFA2scRJonRQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 698F3802935; Mon, 27 Sep 2021 06:42:31 +0000 (UTC) Received: from gshan.redhat.com (vpn2-54-16.bne.redhat.com [10.64.54.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3499960936; Mon, 27 Sep 2021 06:42:26 +0000 (UTC) From: Gavin Shan To: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, robh@kernel.org, maz@kernel.org, rdunlap@infradead.org, catalin.marinas@arm.com, will@kernel.org, shan.gavin@gmail.com Subject: [PATCH v2 2/2] of, numa: Fetch empty NUMA node ID from distance map Date: Mon, 27 Sep 2021 14:41:19 +0800 Message-Id: <20210927064119.127285-3-gshan@redhat.com> In-Reply-To: <20210927064119.127285-1-gshan@redhat.com> References: <20210927064119.127285-1-gshan@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org There is no device node for the empty NUMA node. However, the corresponding NUMA node ID and distance map is still valid in "numa-distance-map-v1" compatible device node. This fetches the NUMA node ID and distance map for these empty NUMA node from "numa-distance-map-v1" compatible device node. Signed-off-by: Gavin Shan --- drivers/of/of_numa.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c index fe6b13608e51..5949829a1b00 100644 --- a/drivers/of/of_numa.c +++ b/drivers/of/of_numa.c @@ -111,6 +111,8 @@ static int __init of_numa_parse_distance_map_v1(struct device_node *map) return -EINVAL; } + node_set(nodea, numa_nodes_parsed); + numa_set_distance(nodea, nodeb, distance); /* Set default distance of node B->A same as A->B */