Re: Odd square bracket encoding in QOM names

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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
> 
>