Odd square bracket encoding in QOM names

Odd square bracket encoding in QOM names

[Mark Cave-Ayland]

Hi all,

Has there been a recent change as to how square brackets are encoded within QOM 
names? I noticed that the output has changed here in the "info qom-tree" output in 
qemu-system-m68k for the q800 machine.

The q800 machine has a set of 256 memory region aliases that used to appear in the 
"info qom-tree" output as:

     /mac_m68k.io[100] (memory-region)
     /mac_m68k.io[101] (memory-region)
     /mac_m68k.io[102] (memory-region)

but they now appear as:

     /mac_m68k.io\x5b100\x5d[0] (memory-region)
     /mac_m68k.io\x5b101\x5d[0] (memory-region)
     /mac_m68k.io\x5b102\x5d[0] (memory-region)

Is there something that could cause the names to be double-encoded before being 
displayed?


ATB,

Mark.

Re: Odd square bracket encoding in QOM names

[Michal Prívozník]

On 11/30/21 09:35, Mark Cave-Ayland wrote:
> Hi all,
> 
> Has there been a recent change as to how square brackets are encoded
> within QOM names? I noticed that the output has changed here in the
> "info qom-tree" output in qemu-system-m68k for the q800 machine.
> 
> The q800 machine has a set of 256 memory region aliases that used to
> appear in the "info qom-tree" output as:
> 
>     /mac_m68k.io[100] (memory-region)
>     /mac_m68k.io[101] (memory-region)
>     /mac_m68k.io[102] (memory-region)
> 
> but they now appear as:
> 
>     /mac_m68k.io\x5b100\x5d[0] (memory-region)
>     /mac_m68k.io\x5b101\x5d[0] (memory-region)
>     /mac_m68k.io\x5b102\x5d[0] (memory-region)
> 
> Is there something that could cause the names to be double-encoded
> before being displayed?

I see the same behavior on x86_64 and qemu-system-x86_64 but with a
different member:

/machine (pc-i440fx-4.0-machine)
  /device-memory[0] (memory-region)
  /fw_cfg (fw_cfg_io)
    /\x2from@etc\x2facpi\x2frsdp[0] (memory-region)
    /\x2from@etc\x2facpi\x2ftables[0] (memory-region)
    /\x2from@etc\x2ftable-loader[0] (memory-region)

And the same happens over QMP too:

virsh qemu-monitor-command $dom qom-list '"path":"/machine/fw_cfg"'

{"return":[{"name":"type","type":"string"},{"name":"parent_bus","type":"link<bus>"},{"name":"realized","type":"bool"},{"name":"hotplugged","type":"bool"},{"name":"hotpluggable","type":"bool"},{"name":"acpi-mr-restore","type":"bool"},{"name":"x-file-slots","type":"uint16"},{"name":"dma_enabled","type":"bool"},{"name":"\\x2from@etc\\x2facpi\\x2ftables[0]","type":"child<memory-region>"},{"name":"fwcfg.dma[0]","type":"child<memory-region>"},{"name":"fwcfg[0]","type":"child<memory-region>"},{"name":"\\x2from@etc\\x2facpi\\x2frsdp[0]","type":"child<memory-region>"},{"name":"\\x2from@etc\\x2ftable-loader[0]","type":"child<memory-region>"}],"id":"libvirt-455"}

Michal

Re: Odd square bracket encoding in QOM names

[Philippe Mathieu-Daudé]

On 11/30/21 10:41, Michal Prívozník wrote:
> On 11/30/21 09:35, Mark Cave-Ayland wrote:
>> Hi all,
>>
>> Has there been a recent change as to how square brackets are encoded
>> within QOM names? I noticed that the output has changed here in the
>> "info qom-tree" output in qemu-system-m68k for the q800 machine.
>>
>> The q800 machine has a set of 256 memory region aliases that used to
>> appear in the "info qom-tree" output as:
>>
>>     /mac_m68k.io[100] (memory-region)
>>     /mac_m68k.io[101] (memory-region)
>>     /mac_m68k.io[102] (memory-region)
>>
>> but they now appear as:
>>
>>     /mac_m68k.io\x5b100\x5d[0] (memory-region)
>>     /mac_m68k.io\x5b101\x5d[0] (memory-region)
>>     /mac_m68k.io\x5b102\x5d[0] (memory-region)
>>
>> Is there something that could cause the names to be double-encoded
>> before being displayed?
> 
> I see the same behavior on x86_64 and qemu-system-x86_64 but with a
> different member:
> 
> /machine (pc-i440fx-4.0-machine)
>   /device-memory[0] (memory-region)
>   /fw_cfg (fw_cfg_io)
>     /\x2from@etc\x2facpi\x2frsdp[0] (memory-region)
>     /\x2from@etc\x2facpi\x2ftables[0] (memory-region)
>     /\x2from@etc\x2ftable-loader[0] (memory-region)

This is memory_region_escape_name() in memory_region_do_init().

#2  0x5dd1740 in object_property_add_child (obj=0x6bfe3f0,
name=0x66a7900 "\\x2from@etc\\x2ftable-loader[*]", child=0x70a93e0) at
qom/object.c:1761
#3  0x5c73182 in memory_region_do_init (mr=0x70a93e0, owner=0x6bfe3f0,
name=0x7fffffffd290 "/rom@etc/table-loader", size=4096) at
softmmu/memory.c:1182
#4  0x5c731f1 in memory_region_init (mr=0x70a93e0, owner=0x6bfe3f0,
name=0x7fffffffd290 "/rom@etc/table-loader", size=4096) at
softmmu/memory.c:1195
#5  0x5c73fcd in memory_region_init_resizeable_ram (mr=0x70a93e0,
owner=0x6bfe3f0, name=0x7fffffffd290 "/rom@etc/table-loader", size=4096,
max_size=65536, resized=
    0x597cb6d <fw_cfg_resized>, errp=0x6611780 <error_fatal>) at
softmmu/memory.c:1572
#6  0x597cc18 in rom_set_mr (rom=0x7956c00, owner=0x6bfe3f0,
name=0x7fffffffd290 "/rom@etc/table-loader", ro=true) at
hw/core/loader.c:946
#7  0x597d428 in rom_add_blob
    (name=0x60fed25 "etc/table-loader", blob=0x7968200, len=4096,
max_len=65536, addr=18446744073709551615, fw_file_name=0x60fed25
"etc/table-loader", fw_callback=0x5be0137 <acpi_build_update>,
callback_opaque=0x794b980, as=0x0, read_only=true) at hw/core/loader.c:1086
#8  0x59363a9 in acpi_add_rom_blob (update=0x5be0137
<acpi_build_update>, opaque=0x794b980, blob=0x69ddca0, name=0x60fed25
"etc/table-loader")
    at hw/acpi/utils.c:46
#9  0x5be03b7 in acpi_setup () at hw/i386/acpi-build.c:2820

Wasn't it always like that with fw_cfg?

> And the same happens over QMP too:
> 
> virsh qemu-monitor-command $dom qom-list '"path":"/machine/fw_cfg"'
> 
> {"return":[{"name":"type","type":"string"},{"name":"parent_bus","type":"link<bus>"},{"name":"realized","type":"bool"},{"name":"hotplugged","type":"bool"},{"name":"hotpluggable","type":"bool"},{"name":"acpi-mr-restore","type":"bool"},{"name":"x-file-slots","type":"uint16"},{"name":"dma_enabled","type":"bool"},{"name":"\\x2from@etc\\x2facpi\\x2ftables[0]","type":"child<memory-region>"},{"name":"fwcfg.dma[0]","type":"child<memory-region>"},{"name":"fwcfg[0]","type":"child<memory-region>"},{"name":"\\x2from@etc\\x2facpi\\x2frsdp[0]","type":"child<memory-region>"},{"name":"\\x2from@etc\\x2ftable-loader[0]","type":"child<memory-region>"}],"id":"libvirt-455"}
> 
> Michal
> 
> 

Re: Odd square bracket encoding in QOM names

[Peter Maydell]

On Tue, 30 Nov 2021 at 08:36, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> Has there been a recent change as to how square brackets are encoded within QOM
> names? I noticed that the output has changed here in the "info qom-tree" output in
> qemu-system-m68k for the q800 machine.
>
> The q800 machine has a set of 256 memory region aliases that used to appear in the
> "info qom-tree" output as:
>
>      /mac_m68k.io[100] (memory-region)
>      /mac_m68k.io[101] (memory-region)
>      /mac_m68k.io[102] (memory-region)
>
> but they now appear as:
>
>      /mac_m68k.io\x5b100\x5d[0] (memory-region)
>      /mac_m68k.io\x5b101\x5d[0] (memory-region)
>      /mac_m68k.io\x5b102\x5d[0] (memory-region)

I looked at info qom-tree for an Arm machine, and the [..] seem to be
OK there. I tried to test with q800 but got stuck on finding a
command line to get it to run. Do you have repro instructions?

thanks
-- PMM

Re: Odd square bracket encoding in QOM names

[Mark Cave-Ayland]

On 30/11/2021 16:41, Peter Maydell wrote:

> On Tue, 30 Nov 2021 at 08:36, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>> Has there been a recent change as to how square brackets are encoded within QOM
>> names? I noticed that the output has changed here in the "info qom-tree" output in
>> qemu-system-m68k for the q800 machine.
>>
>> The q800 machine has a set of 256 memory region aliases that used to appear in the
>> "info qom-tree" output as:
>>
>>       /mac_m68k.io[100] (memory-region)
>>       /mac_m68k.io[101] (memory-region)
>>       /mac_m68k.io[102] (memory-region)
>>
>> but they now appear as:
>>
>>       /mac_m68k.io\x5b100\x5d[0] (memory-region)
>>       /mac_m68k.io\x5b101\x5d[0] (memory-region)
>>       /mac_m68k.io\x5b102\x5d[0] (memory-region)
> 
> I looked at info qom-tree for an Arm machine, and the [..] seem to be
> OK there. I tried to test with q800 but got stuck on finding a
> command line to get it to run. Do you have repro instructions?

A couple of tests this evening and I think I must have misremembered this - I tried a 
couple of older versions of my various q800 branches (one within the 6.0 dev cycle 
and another within 6.1) and both escape the QOM object name in "info qom-tree" the 
same way as above.

Easiest way to see this is to grab Finn's kernel from issue #611 like this:

$ wget 
https://gitlab.com/qemu-project/qemu/uploads/dead759323116fb22cf0f03b8cdbe15a/vmlinux-5.14-multi.xz
$ unxz vmlinux-5.14-multi.xz

And then start QEMU with this command line:

$ ./qemu-system-m68k -M q800 -kernel vmlinux-5.14-multi -monitor stdio -S

Obviously the cause is the use of square brackets within the memory region name as 
per https://gitlab.com/qemu-project/qemu/-/blob/master/hw/m68k/q800.c#L411, so given 
the escaping has been like this for some time then I guess everything is working as 
intended, and sorry for the noise.


ATB,

Mark.