qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Odd square bracket encoding in QOM names


From: Mark Cave-Ayland
Subject: Re: Odd square bracket encoding in QOM names
Date: Tue, 30 Nov 2021 18:44:10 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]