The node unit addresses should be based on the reg value (which is in
turn based on MPIDR), rather than some arbitrary number [1]. Also, they
should have been in hex, not decimal, as per de facto convention [2].
Fix them.
Link: https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#devicetree-structure-and-conventions # [1]
Link: https://lore.kernel.org/devicetree-spec/CAL_JsqJFv3+UJ-bjLGk0i7Wc+spsowCrqQZ_s3P4gN8r1W-Q-w@mail.gmail.com/ # [2]
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
---
hw/arm/sbsa-ref.c | 4 ++--
hw/arm/virt.c | 7 +++++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 52c35e10c2..7fd631bff5 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -259,10 +259,10 @@ static void create_fdt(SBSAMachineState *sms)
qemu_fdt_setprop_cell(sms->fdt, "/cpus", "#size-cells", 0x0);
for (cpu = sms->smp_cpus - 1; cpu >= 0; cpu--) {
- char *nodename = g_strdup_printf("/cpus/cpu@%d", cpu);
+ uint64_t mpidr = sbsa_ref_cpu_mp_affinity(sms, cpu);
+ char *nodename = g_strdup_printf("/cpus/cpu@%" PRIx64, mpidr);
ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(cpu));
CPUState *cs = CPU(armcpu);
- uint64_t mpidr = sbsa_ref_cpu_mp_affinity(sms, cpu);
qemu_fdt_add_subnode(sms->fdt, nodename);
qemu_fdt_setprop_u64(sms->fdt, nodename, "reg", mpidr);
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index ec0d8475ca..20d62cc311 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -466,8 +466,9 @@ static void fdt_add_cpu_nodes(const VirtMachineState *vms)
qemu_fdt_setprop_cell(ms->fdt, "/cpus", "#size-cells", 0x0);
for (cpu = smp_cpus - 1; cpu >= 0; cpu--) {
- char *nodename = g_strdup_printf("/cpus/cpu@%d", cpu);
ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(cpu));
+ char *nodename = g_strdup_printf("/cpus/cpu@%" PRIx64,
+ arm_cpu_mp_affinity(armcpu));
CPUState *cs = CPU(armcpu);
qemu_fdt_add_subnode(ms->fdt, nodename);
@@ -521,7 +522,9 @@ static void fdt_add_cpu_nodes(const VirtMachineState *vms)
qemu_fdt_add_subnode(ms->fdt, "/cpus/cpu-map");
for (cpu = smp_cpus - 1; cpu >= 0; cpu--) {
- char *cpu_path = g_strdup_printf("/cpus/cpu@%d", cpu);
+ ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(cpu));
+ char *cpu_path = g_strdup_printf("/cpus/cpu@%" PRIx64,
+ arm_cpu_mp_affinity(armcpu));
char *map_path;
if (ms->smp.threads > 1) {
--
2.53.0On 9/4/26 08:40, Vivian Wang wrote:
> The node unit addresses should be based on the reg value (which is in
> turn based on MPIDR), rather than some arbitrary number [1]. Also, they
> should have been in hex, not decimal, as per de facto convention [2].
> Fix them.
>
Maybe worth to add:
Cc: qemu-stable@nongnu.org
> Link: https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#devicetree-structure-and-conventions # [1]
> Link: https://lore.kernel.org/devicetree-spec/CAL_JsqJFv3+UJ-bjLGk0i7Wc+spsowCrqQZ_s3P4gN8r1W-Q-w@mail.gmail.com/ # [2]
> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
> ---
> hw/arm/sbsa-ref.c | 4 ++--
> hw/arm/virt.c | 7 +++++--
> 2 files changed, 7 insertions(+), 4 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
On 4/9/26 17:39, Philippe Mathieu-Daudé wrote: > On 9/4/26 08:40, Vivian Wang wrote: >> The node unit addresses should be based on the reg value (which is in >> turn based on MPIDR), rather than some arbitrary number [1]. Also, they >> should have been in hex, not decimal, as per de facto convention [2]. >> Fix them. >> > > Maybe worth to add: > > Cc: qemu-stable@nongnu.org > As Peter Maydell mentioned in other replies in this thread, most software don't really care about these node names, so I don't think this needs backporting to stable. I'm unsure if this is still worth fixing then. Peter expressed that it's not something worth fixing. Thanks for your review, Vivian "dramforever" Wang >> Link: >> https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#devicetree-structure-and-conventions >> # [1] >> Link: >> https://lore.kernel.org/devicetree-spec/CAL_JsqJFv3+UJ-bjLGk0i7Wc+spsowCrqQZ_s3P4gN8r1W-Q-w@mail.gmail.com/ >> # [2] >> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> >> --- >> hw/arm/sbsa-ref.c | 4 ++-- >> hw/arm/virt.c | 7 +++++-- >> 2 files changed, 7 insertions(+), 4 deletions(-) > > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
On Thu, 9 Apr 2026 at 10:46, Vivian Wang <wangruikang@iscas.ac.cn> wrote: > > On 4/9/26 17:39, Philippe Mathieu-Daudé wrote: > > On 9/4/26 08:40, Vivian Wang wrote: > >> The node unit addresses should be based on the reg value (which is in > >> turn based on MPIDR), rather than some arbitrary number [1]. Also, they > >> should have been in hex, not decimal, as per de facto convention [2]. > >> Fix them. > >> > > > > Maybe worth to add: > > > > Cc: qemu-stable@nongnu.org > > > As Peter Maydell mentioned in other replies in this thread, most > software don't really care about these node names, so I don't think this > needs backporting to stable. > > I'm unsure if this is still worth fixing then. Peter expressed that it's > not something worth fixing. For the virt board, I think it depends whether the spec really says that the node name must have the MPIDR in it and that consumers can rely on that as a source of the MPIDR. I hope it does not. If it's just a node name, then I don't see why it matters what node name we generate as long as we're not generating the same nodename twice. We're not trying to generate DT files that are intended for submission upstream. There are other places where our nodenames don't match the conventions upstream prefers; I generally prefer not to mess with the existing working code in QEMU unless there's something actually broken about what we're doing. Thread from the last time this came up: https://lore.kernel.org/qemu-devel/CAFEAcA9OWDiWh3S=0Co7Z27EtOp-1B9H7FxyQy1T2sFnTyNdqA@mail.gmail.com/ Essentially, the set of things that it makes sense to have a convention for and perhaps to validate for a hand-written DTS file is stricter than the set of actual requirements for a generated DTB, and I prefer not to potentially break some guest code that's looking for a particular node name purely to bring us in to line with conventions intended for hand-written DTS files. thanks -- PMM
On 4/9/26 18:01, Peter Maydell wrote: > On Thu, 9 Apr 2026 at 10:46, Vivian Wang <wangruikang@iscas.ac.cn> wrote: >> On 4/9/26 17:39, Philippe Mathieu-Daudé wrote: >>> On 9/4/26 08:40, Vivian Wang wrote: >>>> The node unit addresses should be based on the reg value (which is in >>>> turn based on MPIDR), rather than some arbitrary number [1]. Also, they >>>> should have been in hex, not decimal, as per de facto convention [2]. >>>> Fix them. >>>> >>> Maybe worth to add: >>> >>> Cc: qemu-stable@nongnu.org >>> >> As Peter Maydell mentioned in other replies in this thread, most >> software don't really care about these node names, so I don't think this >> needs backporting to stable. >> >> I'm unsure if this is still worth fixing then. Peter expressed that it's >> not something worth fixing. > For the virt board, I think it depends whether the spec really says > that the node name must have the MPIDR in it and that consumers > can rely on that as a source of the MPIDR. I hope it does not. > If it's just a node name, then I don't see why it matters what > node name we generate as long as we're not generating the same > nodename twice. We're not trying to generate DT files that are > intended for submission upstream. > > There are other places where our nodenames don't match the > conventions upstream prefers; I generally prefer not to mess with > the existing working code in QEMU unless there's something actually > broken about what we're doing. Thread from the last time this came up: > > https://lore.kernel.org/qemu-devel/CAFEAcA9OWDiWh3S=0Co7Z27EtOp-1B9H7FxyQy1T2sFnTyNdqA@mail.gmail.com/ > > Essentially, the set of things that it makes sense to have a > convention for and perhaps to validate for a hand-written DTS > file is stricter than the set of actual requirements for a > generated DTB, and I prefer not to potentially break some > guest code that's looking for a particular node name purely > to bring us in to line with conventions intended for > hand-written DTS files. Thanks for the explanation. I can understand that these DTBs don't really need to be held up to the same standards/pedantry as Linux upstream DTS files. Thanks, Vivian "dramforever" Wang
On Thu, 9 Apr 2026 at 10:39, Philippe Mathieu-Daudé <philmd@linaro.org> wrote: > > On 9/4/26 08:40, Vivian Wang wrote: > > The node unit addresses should be based on the reg value (which is in > > turn based on MPIDR), rather than some arbitrary number [1]. Also, they > > should have been in hex, not decimal, as per de facto convention [2]. > > Fix them. > > > > Maybe worth to add: > > Cc: qemu-stable@nongnu.org Why? What bug is this fixing? -- PMM
On Thu, 9 Apr 2026 at 07:40, Vivian Wang <wangruikang@iscas.ac.cn> wrote: > > The node unit addresses should be based on the reg value (which is in > turn based on MPIDR), rather than some arbitrary number [1]. Also, they > should have been in hex, not decimal, as per de facto convention [2]. > Fix them. Please don't fix multiple different things in one patch. In particular, sbsa-ref is special: the "dtb" it produces is not intended to be an actual DTB, it's just a convenient way to pass a tiny amount of information to the firmware for this board. We talk about this in the docs: https://www.qemu.org/docs/master/system/arm/sbsa.html#board-to-firmware-interface The firmware doesn't need the MPIDR in the node name, so there's no real need to change this. thanks -- PMM
© 2016 - 2026 Red Hat, Inc.