On Tue, Oct 6, 2026 at 2:52 AM Pierrick Bouvier
<[email protected]> wrote:
>
> 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.
because for different SysEmuTarget, the machine list is different.
return a wrong SysEmuTarget would cause a mismatch between SysEmuTarget
and the machine list. for example:
static const char * const mips_machines[] = {
"malta",
"none",
};
static const char * const mips64_machines[] = {
"magnum",
"malta",
"none",
"pica61",
};
static const char * const mips64el_machines[] = {
"boston",
"fuloong2e",
"loongson3-virt",
"magnum",
"malta",
"none",
"pica61",
};
static const char * const mipsel_machines[] = {
"malta",
"none",
};
>
> 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
> >>>>
> >>>
> >>>
> >>
> >
> >
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
