On Tue, Oct 6, 2026 at 12:25 AM Pierrick Bouvier <[email protected]> wrote: > > On 10/5/2026 9:19 AM, Yonggang Luo wrote: > > On Tue, Oct 6, 2026 at 12:12 AM Pierrick Bouvier > > <[email protected]> wrote: > >> > >> On 10/5/2026 9:10 AM, Yonggang Luo wrote: > >>> On Tue, Oct 6, 2026 at 12:03 AM Pierrick Bouvier > >>> <[email protected]> wrote: > >>>> > >>>> On 10/4/2026 12:29 AM, Yonggang Luo wrote: > >>>>> `TARGET_ARCH` identifies a base architecture, not necessarily the full > >>>>> system-emulation target. For example, `mipsel-softmmu` uses > >>>>> `TARGET_ARCH=mips`, > >>>>> which caused `query-target` to report `mips` instead of `mipsel`. > >>>>> > >>>>> Generate `TARGET_SYS_EMU` separately. Softmmu builds use the full > >>>>> target name, > >>>>> as `SysEmuTarget` enumerates system targets. User-mode builds use > >>>>> `TARGET_ARCH`: user target names such as `aarch64_be` and `mipsn32el` > >>>>> do not > >>>>> have corresponding `SysEmuTarget` values. This means > >>>>> `mipsel-linux-user` now > >>>>> reports the base architecture `mips` rather than `mipsel`; its > >>>>> executable name > >>>>> remains unchanged. Initialize `TargetInfo.target_arch` from this token > >>>>> and add > >>>>> a qtest to check the `query-target` result against the target name of > >>>>> the > >>>>> running QEMU binary. > >>>>> > >>>>> Yonggang Luo (4): > >>>>> Revert "target-info: Statically initialize target_arch" > >>>>> Revert "meson: Add TARGET_ARCH to config_target_data" > >>>>> tests/qtest: check query-target architecture > >>>>> target-info: preserve full softmmu target identity > >>>>> > >>>>> meson.build | 11 +++++++++-- > >>>>> target-info-stub.c | 2 +- > >>>>> tests/qtest/qmp-test.c | 13 +++++++++++++ > >>>>> 3 files changed, 23 insertions(+), 3 deletions(-) > >>>>> > >>>> > >>>> Why should we do this for user binaries? Current work around > >>>> single-binary only concerns system binaries, where all targets are > >>>> correctly covered by what exists. > >>> > >>> From my personal point of view, keeping target_arch as > >>> SYS_EMU_TARGET__MAX for user binaries > >>> is a better option. I am doing this is for replica of commit > >>> > >> > >> 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.
Yeap, but this functional change caused me have to add endianness into query-targets at https://lore.kernel.org/qemu-devel/cae2xoe_fxtrqjpzsdzhs44z65kr0e54cwjvpyzqgtr1sdlo...@mail.gmail.com/ because in the current qemu tip, The $arch returned by query-target not match the qemu-sytem-$arch anymore. > > > > >> > >>> "target-info: Statically initialize target_arch" > >>> > >>>> > >>>> Regards, > >>>> Pierrick > >>> > >>> > >>> > >> > > > > -- > > 此致 > > 礼 > > 罗勇刚 > > Yours > > sincerely, > > Yonggang Luo > -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
