On 10/6/2026 11:46 AM, Yonggang Luo wrote: > where I do not see it > I wonder if list is down, I don't see any new thread on it...
> > 此致 > 礼 > 罗勇刚 > Yours > sincerely, > Yonggang Luo > > Pierrick Bouvier <[email protected] > <mailto:[email protected]>> 于 2026年10月7日周三 02:30写道： > > 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] > <mailto:[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] > <mailto:[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] > <mailto:[email protected]> > "[PATCH 0/2] target-info: expose full target variant" > > Regards, > Pierrick >
