On 10/6/2026 6:56 AM, Daniel P. Berrangé wrote: > 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
Thanks for finding this Daniel. SYS_EMU_TARGET already has the correct variants, the regression was to use TARGET_ARCH instead of TARGET_NAME in target-info-stub.c. I think Richard used this one just because TARGET_NAME is a string, so it can't be concatenated with C preprocessor. I'll fix that part. Regards, Pierrick
