devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gavin Shan <gshan@redhat.com>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	rdunlap@infradead.org, drjones@redhat.com, shan.gavin@gmail.com
Subject: Re: [PATCH v5] Documentation, dt, numa: Add note to empty NUMA node
Date: Sun, 11 Jul 2021 10:59:58 +1000	[thread overview]
Message-ID: <6168ef6a-53a0-403c-0412-0ec3c0546c61@redhat.com> (raw)
In-Reply-To: <1c43cd39-7bf6-b99c-36ec-798b81b1aba1@redhat.com>

Hi Rob,

On 7/2/21 10:02 AM, Gavin Shan wrote:
> On 7/2/21 3:25 AM, Rob Herring wrote:
>> On Mon, Jun 28, 2021 at 05:34:11PM +0800, Gavin Shan wrote:
>>> The empty memory nodes, where no memory resides in, are allowed.
>>> For these empty memory nodes, the 'len' of 'reg' property is zero.
>>> The NUMA node IDs are still valid and parsed, but memory may be
>>> added to them through hotplug afterwards. I finds difficulty to
>>> get where it's properly documented.
>>
>> This is already in use? If so, what platform(s)?
>>
> 
> It's not used yet, but will be used by QEMU once this patch is merged.
> In QEMU, ARM64 could have multiple empty memory nodes. The corresponding
> NUMA ID and distance map are still valid because memory may be added into
> these empty memory nodes in future.
> 
> For the QEMU case, the names of empty memory nodes are the biggest concern.
> According to device-tree specification, the name follows the format of
> 'memory@unit-address' and the 'unit-address' is equivalent to 'base-address'.
> However, the 'base-address' should be invalid one. In current QEMU implementation,
> the valid 'base-address' and 'unit-address' are provided to these empty
> memory nodes. Another issue in QEMU is trying to populate two empty memory
> nodes, which have same names. This leads to failure of device-tree population
> because of the duplicated memory node names, blocking VM from booting.
> 
>>> So lets add a section for empty memory nodes in NUMA binding
>>> document. Also, the 'unit-address', equivalent to 'base-address'
>>> in the 'reg' property of these empty memory nodes is suggested to
>>> be the summation of highest memory address plus the NUMA node ID.
>>
>> What purpose does this serve? The kernel won't do anything with it other
>> than validate the numa-node-id range.
>>
> 
> As mentioned above, the point is to have dummy, invalid and non-overlapped
> 'base-address' and 'unit-address' for these empty memory nodes, to avoid
> duplicated memory node names in devcie-tree.
> 
>>>
>>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>>> ---
>>> v5: Separate section for empty memory node
>>> ---
>>>   Documentation/devicetree/bindings/numa.txt | 61 +++++++++++++++++++++-
>>>   1 file changed, 60 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt
>>> index 21b35053ca5a..230c734af948 100644
>>> --- a/Documentation/devicetree/bindings/numa.txt
>>> +++ b/Documentation/devicetree/bindings/numa.txt
>>> @@ -103,7 +103,66 @@ Example:
>>>           };
>>>   ==============================================================================
>>> -4 - Example dts
>>> +4 - Empty memory nodes
>>> +==============================================================================
>>> +
>>> +Empty memory nodes, which no memory resides in, are allowed. The 'length'
>>> +field of the 'reg' property is zero, but the 'base-address' is a dummy
>>> +address and invalid. The 'base-address' could be the summation of highest
>>> +memory address plus the NUMA node ID. 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@0x80000000 {
>>
>> unit-address should not have '0x'.
>>
> 
> Ok. Lets fix it in v6 after it's agreed to add the section into the
> NUMA binding document. Actually, the '0x' is copied from the existing
> example in same document. After this patch is finalized, I will post
> separate patch to fix all wrong formats in same document as well.
> 

I posted v6 just now, where '0x' in 'unit-address' is dropped. After
this is merged, I will post followup patch to remove '0x' in 'unit-address'
for existing examples.

Thanks,
Gavin

>>> +        device_type = "memory";
>>> +        reg = <0x0 0x80000000 0x0 0x80000000>;
>>> +        numa-node-id = <1>;
>>> +    };
>>> +
>>> +    /* Empty memory node */
>>> +    memory@0x100000002 {
>>> +        device_type = "memory";
>>> +        reg = <0x1 0x2 0x0 0x0>;
>>> +        numa-node-id = <2>;
>>> +    };
>>> +
>>> +    /* Empty memory node */
>>> +    memory@0x100000003 {
>>> +        device_type = "memory";
>>> +        reg = <0x1 0x3 0x0 0x0>;
>>> +        numa-node-id = <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
>>> -- 


  reply	other threads:[~2021-07-11  1:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28  9:34 [PATCH v5] Documentation, dt, numa: Add note to empty NUMA node Gavin Shan
2021-06-28 16:15 ` Randy Dunlap
2021-06-30  7:26   ` Gavin Shan
2021-07-01 17:25 ` Rob Herring
2021-07-02  0:02   ` Gavin Shan
2021-07-11  0:59     ` Gavin Shan [this message]
2021-07-12 19:44     ` Rob Herring
2021-07-15  4:54       ` Gavin Shan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6168ef6a-53a0-403c-0412-0ec3c0546c61@redhat.com \
    --to=gshan@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drjones@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=robh@kernel.org \
    --cc=shan.gavin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).