On 10/6/2026 12:32 PM, Pierrick Bouvier wrote: > 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... >
It seems to be down for now. ----- Transcript of session follows ----- <[email protected]>... Deferred: eggs.gnu.org.: No route to host Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old I'll wait and resend the series when it's back. >> >> 此致 >> 礼 >> 罗勇刚 >> 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 >> >
