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.
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
> >>
> >
> >
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
