On Mon, Oct 05, 2026 at 11:52:48AM -0700, Pierrick Bouvier wrote:
> On 10/5/2026 11:45 AM, Yonggang Luo wrote:
> > On Tue, Oct 6, 2026 at 2:06 AM Pierrick Bouvier
> > <[email protected]> wrote:
> >>
> >> On 10/5/2026 10:04 AM, Yonggang Luo wrote:
> >>> On Tue, Oct 6, 2026 at 12:25 AM Pierrick Bouvier
> >>> <[email protected]> wrote:
> >>>>>>
> >>>>>> Ok, but I'm not sure it answers the why.
> >>>>>> Could you explain the benefits?
> >>>>>
> >>>>> Which part? keeping target_arch as SYS_EMU_TARGET__MAX for user-binary
> >>>>> because
> >>>>> The following original code would return -1 for some user-binary
> >>>>> + SysEmuTarget arch = target_info()->target_arch;
> >>>>> +
> >>>>> + if (arch == SYS_EMU_TARGET__MAX) {
> >>>>> + arch = qapi_enum_parse(&SysEmuTarget_lookup, target_name(), -1,
> >>>>> + &error_abort);
> >>>>> + }
> >>>>> + return arch;
> >>>>> So basically assigning any value for the user binary is valid.
> >>>>> SYS_EMU_TARGET__MAX is more explicit as it's related to type
> >>>>> SysEmuTarget.
> >>>>> -1 is another option but easy to confuse.
> >>>>>
> >>>>>
> >>>>> For why commit e934c624f32f6f44f427d73a2e6a67e983a02ae6.
> >>>>> "target-info: Statically initialize target_arch"
> >>>>> doing that, I am not sure.
> >>>>>
> >>>>
> >>>> I guess there is a (good or bad) reason for which sub variants of
> >>>> targets are not reflected in SYS_EMU_TARGET enum. We should double check
> >>>> that before doing any change, as it might have other consequences.
> >>>
> >>>
> >>> You’re right to ask, and I need to correct my earlier suggestion:
> >>> leaving user-mode target_arch
> >>> as SYS_EMU_TARGET__MAX is not safe. target_aarch64() is used by ARM
> >>> code shared with user-mode builds,
> >>> including cpu-max-v8.c, where its result indexes a two-entry array.
> >>> For aarch64-linux-user, the sentinel could therefore cause an
> >>> out-of-bounds access during type registration.
> >>>
> >>> I checked the distinction: softmmu needs the full system-target
> >>> identity, including variants such as mipsel;
> >>> user-mode variants such as aarch64_be use their base TARGET_ARCH
> >>> (aarch64) for this enum. I’ll keep the full TARGET_SYS_EMU
> >>> value for softmmu and use TARGET_ARCH for user-mode builds, rather
> >>> than leave the field at SYS_EMU_TARGET__MAX.
> >>>
> >>
> >> That's technical details, but not an answer to the initial question of
> >> why we need to change anything for user binaries, compared to what exists.
> >
> > The first two patches revert the current static initialization so the
> > token can be replaced. They are not a user-mode behavior change.
> >
> > Compared with current QEMU, user-mode still uses TARGET_ARCH.
> > qemu-mipsel already reports mips, and it still will. Names such as
> > aarch64_be are not SysEmuTarget values, so user-mode cannot use the
> > full target name for this field; keeping TARGET_ARCH preserves today's
> > value and avoids the runtime parse.
> >
>
> Why should we need to expose this precise information?
> So far, if those targets were not exposed (and aliased to 32/64 bit
> variant), it's probably we didn't need it.
Current git master is exhibiting a regression compared to previous
releases.
For example on 10.1.0:
$ for i in /usr/bin/qemu-system-* ; do echo -n "$i: " ; echo -e
'{"execute":"qmp_capabilities"}\r\n{"execute":"query-target"}\r\n{"execute":"quit"}\r\n'
| $i -qmp stdio -display none -M none | jq .return.arch | grep -v null ; done
/usr/bin/qemu-system-aarch64: "aarch64"
/usr/bin/qemu-system-alpha: "alpha"
/usr/bin/qemu-system-arm: "arm"
/usr/bin/qemu-system-avr: "avr"
/usr/bin/qemu-system-hppa: "hppa"
/usr/bin/qemu-system-i386: "i386"
/usr/bin/qemu-system-loongarch64: "loongarch64"
/usr/bin/qemu-system-m68k: "m68k"
/usr/bin/qemu-system-microblaze: "microblaze"
/usr/bin/qemu-system-microblazeel: "microblazeel"
/usr/bin/qemu-system-mips: "mips"
/usr/bin/qemu-system-mips64: "mips64"
/usr/bin/qemu-system-mips64el: "mips64el"
/usr/bin/qemu-system-mipsel: "mipsel"
/usr/bin/qemu-system-or1k: "or1k"
/usr/bin/qemu-system-ppc: "ppc"
/usr/bin/qemu-system-ppc64: "ppc64"
/usr/bin/qemu-system-riscv32: "riscv32"
/usr/bin/qemu-system-riscv64: "riscv64"
/usr/bin/qemu-system-rx: "rx"
/usr/bin/qemu-system-s390x: "s390x"
/usr/bin/qemu-system-sh4: "sh4"
/usr/bin/qemu-system-sh4eb: "sh4eb"
/usr/bin/qemu-system-sparc: "sparc"
/usr/bin/qemu-system-sparc64: "sparc64"
/usr/bin/qemu-system-tricore: "tricore"
/usr/bin/qemu-system-x86_64: "x86_64"
/usr/bin/qemu-system-xtensa: "xtensa"
/usr/bin/qemu-system-xtensaeb: "xtensaeb"
but on git master:
$ for i in $(find ./build -type f -name 'qemu-system-*') ; do echo -n "$i: " ;
echo -e
'{"execute":"qmp_capabilities"}\r\n{"execute":"query-target"}\r\n{"execute":"quit"}\r\n'
| $i -qmp stdio -display none -M none | jq .return.arch | grep -v null ; done
./build/qemu-system-hexagon: "hexagon"
./build/qemu-system-x86_64: "x86_64"
./build/qemu-system-s390x: "s390x"
./build/qemu-system-m68k: "m68k"
./build/qemu-system-xtensa: "xtensa"
./build/qemu-system-xtensaeb: "xtensa"
./build/qemu-system-rx: "rx"
./build/qemu-system-loongarch64: "loongarch64"
./build/qemu-system-riscv32: "riscv32"
./build/qemu-system-hppa: "hppa"
./build/qemu-system-ppc64: "ppc64"
./build/qemu-system-microblaze: "microblaze"
./build/qemu-system-sparc: "sparc"
./build/qemu-system-riscv64: "riscv64"
./build/qemu-system-i386: "i386"
./build/qemu-system-mipsel: "mips"
./build/qemu-system-sh4: "sh4"
./build/qemu-system-mips64el: "mips64"
./build/qemu-system-mips64: "mips64"
./build/qemu-system-sparc64: "sparc64"
./build/qemu-system-arm: "arm"
./build/qemu-system-tricore: "tricore"
./build/qemu-system-mips: "mips"
./build/qemu-system-or1k: "or1k"
./build/qemu-system-sh4eb: "sh4"
./build/qemu-system-aarch64: "aarch64"
./build/qemu-system-ppc: "ppc"
./build/qemu-system-avr: "avr"
./build/qemu-system-alpha: "alpha"
so we need to fix that behaviour change for query-target.
If we want to be able to expose only the "base" target,
then query-target's QemuTargetInfo struct could be
extended with a 2nd field that presents the base.
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
