On Tue, Oct 6, 2026 at 4:53 AM BALATON Zoltan <[email protected]> wrote:
>
> On Tue, 6 Oct 2026, 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 don't know anything about this but for bi-endian architectures the CPU
> still has a default endianness it starts in, or a way to strap it to some
> endianness by a CPU pin or similar, or the board firmware sets the
> endianness (which in QEMU may be implemented in board code where we
> emulate the firmware instead of running a real firmware image, so while on
> real hardware the machine starts in BE then firmware sets LE we only start
> emulating from that point and the board code sets up the CPU to LE in
> QEMU).
>
> In any case, this means that endianness should be a machine property and
> the list for an arch could contain all boards, then if the target arch
> defines an endianness, you compare that to the machine endianness and
> filter out those that don't match.
>
> But from the above list BE machines also seem to appear in LE the list and
> malta appears everywhere so first we should understand how these lists are
> defined. It's not filtering out non-matching machines but maybe "el" just
> adds default LE machines in addition to the mips64 list and magnum and
> pica61 are added due to having 64 bit CPU which is another property to
> watch. So the lists seem to depend on CPU and board properties, in
> particular 64bit and LE.
>
> I don't know if this can be implemented easily or at all with how these
> are currently, but I think going that way could arrive to a cleaner
> implementation. I'm sharing the above in case it helps this topic, I don't
> mind how this is implemented so you can also disregard this, just thinking
> aloud.
SysEmuTarget is the API
##
# @QemuTargetInfo:
# Information on the target configuration built into the QEMU
# binary.
#
# @arch: the target architecture
#
# Since: 1.2
##
{ 'struct': 'QemuTargetInfo',
'data': { 'arch': 'SysEmuTarget' } }
start from qemu 1.2, so keeping its behavior not changed is the most
straightforward way, I don't know why break it
in the first place. If we need narrow to `TARGET_ARCH`, we can always
introduce a new member into
TargetInfo such as config_arch for it. Because the main usage for
`TARGET_ARCH` is reading the Kconfig.
The runtime usage should also reflect that.
here is how its used:
# Add default keys
config_target += { 'TARGET_' + config_target['TARGET_ARCH'].to_upper(): 'y' }
if 'TARGET_BASE_ARCH' not in config_target
config_target += {'TARGET_BASE_ARCH': config_target['TARGET_ARCH']}
endif
if 'TARGET_ABI_DIR' not in config_target
config_target += {'TARGET_ABI_DIR': config_target['TARGET_ARCH']}
endif
>
> Regards,
> BALATON Zoltan
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
