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.
Regards,
BALATON Zoltan
