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()
}
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.
In all cases, that's the first thing to work on before any other step.
Regards,
Pierrick
