On Tue, Oct 6, 2026 at 3:15 AM Pierrick Bouvier
<[email protected]> wrote:
>
> On 10/5/2026 12:06 PM, Yonggang Luo wrote:
> > 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",
> > };
> >
> >
>
> I see, in this case, I would invite you to first work on how to declare
> for which target a machine is available, as discussed with Daniel on a
> previous thread.
>
> What comes out of this will give the answer about how to deal with sub
> variants.
>
> If it's a callback, it should be easy to use:
> is_available_mips64el() {
> target_mips64() && target_big_endian()
> }
That again triggers another issue, the query-machines need to return
the endianness/target_arch() pair
for checking if the machine filtering is implemented valid to match
existing qemu-system-$arch binaries.
>
> If it's a static list of SYS_EMU_TARGET, then the easiest path will
> probably be to extend list of targets in this enum.
No, adding every user-mode target to SYS_EMU_TARGET is not necessary for this
softmmu machine-availability work. All configured softmmu targets already have
matching enum values. The missing variants (aarch64_be, armeb,
microblazeel, mipsn32, mipsn32el, ppc64le, and sparc32plus)
are user-mode-only here, so include them only if the availability
mechanism is intended
to represent user-mode targets too.
>
> In all cases, that's the first thing to work on before any other step.
>
> Regards,
> Pierrick
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
