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. In case there is a real need to expose it, maybe the simplest solution is to add such target configs. > The only intended change is softmmu, where TARGET_NAME differs from > TARGET_ARCH. qemu-system-mipsel must report mipsel, not mips. > > The cover-letter sentence about mipsel-linux-user compared against the > old target_name() parse, not against current QEMU. > > > >> >>>> >>>>> >>>>>> >>>>>>> "target-info: Statically initialize target_arch" >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Pierrick >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> 此致 >>>>> 礼 >>>>> 罗勇刚 >>>>> Yours >>>>> sincerely, >>>>> Yonggang Luo >>>> >>> >>> >> > >
