On 10/6/2026 10:31 AM, Pierrick Bouvier wrote: > 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. >
Please take a look to the following series that solves this regression, and also allows to detect endianness variants through target_arch(): [email protected] "[PATCH 0/2] target-info: expose full target variant" Regards, Pierrick
