On Wed, Oct 14, 2026 at 5:37 AM Pierrick Bouvier
<[email protected]> wrote:
>
> On 10/13/2026 2:30 PM, Yonggang Luo wrote:
> > On Wed, Oct 14, 2026 at 5:07 AM Pierrick Bouvier
> > <[email protected]> wrote:
> >>
> >> On 10/13/26 1:19 PM, Yonggang Luo wrote:
> >>> On Wed, Oct 14, 2026 at 4:08 AM Pierrick Bouvier
> >>> <[email protected]> wrote:
> >>>>
> >>>> On 10/13/2026 12:56 PM, Yonggang Luo wrote:
> >>>>> This is for avoid "max-v8" qom name conflict in multi-target qemu
> >>>>>
> >>>>> Signed-off-by: Yonggang Luo <[email protected]>
> >>>>> ---
> >>>>> target/arm/tcg/cpu-max-v8.c | 17 +++++++++++++----
> >>>>> 1 file changed, 13 insertions(+), 4 deletions(-)
> >>>>>
> >>>>> diff --git a/target/arm/tcg/cpu-max-v8.c b/target/arm/tcg/cpu-max-v8.c
> >>>>> index 65f851f2006..d7323ab431c 100644
> >>>>> --- a/target/arm/tcg/cpu-max-v8.c
> >>>>> +++ b/target/arm/tcg/cpu-max-v8.c
> >>>>> @@ -119,12 +119,21 @@ void aarch32_max_v8_tcg_initfn(Object *obj)
> >>>>> #endif
> >>>>> }
> >>>>>
> >>>>> +static void max_v8_tcg_initfn(Object *obj)
> >>>>> +{
> >>>>> + if (target_aarch64()) {
> >>>>> + aarch64_max_v8_tcg_initfn(obj);
> >>>>> + } else {
> >>>>> + aarch32_max_v8_tcg_initfn(obj);
> >>>>> + }
> >>>>> +}
> >>>>> +
> >>>>> static void cpu_max_v8_register_type(void)
> >>>>> {
> >>>>> - static const ARMCPUInfo max_v8[2] = {
> >>>>> - { .name = "max-v8", .initfn = aarch32_max_v8_tcg_initfn },
> >>>>> - { .name = "max-v8", .initfn = aarch64_max_v8_tcg_initfn },
> >>>>> + static const ARMCPUInfo max_v8 = {
> >>>>> + .name = "max-v8",
> >>>>> + .initfn = max_v8_tcg_initfn,
> >>>>> };
> >>>>> - arm_cpu_register(&max_v8[target_aarch64()]);
> >>>>> + arm_cpu_register(&max_v8);
> >>>>> }
> >>>>> type_init(cpu_max_v8_register_type)
> >>>>
> >>>> It works for the current need, but will require further changes for
> >>>> heterogeneous emulation. A more versatile solution could be:
> >>>>
> >>>> arm_cpu_register(&aarch32_max_v8, target_arm);
> >>>> arm_cpu_register(&aarch64_max_v8, target_aarch64);
> >>>
> >>> And another way to handle it is like x86. it's comes with two variant for
> >>>
> >>> #ifdef TARGET_X86_64
> >>> #define TYPE_X86_CPU "x86_64-cpu"
> >>> #else
> >>> #define TYPE_X86_CPU "i386-cpu"
> >>> #endif
> >>>
> >>> This also solves this issue, which looks more straightforward. no need
> >>> .targets magic for CPU.
> >>> Anyway, maybe the best way is to merge "x86_64-cpu" and "i386-cpu"
> >>> into a single cpu type and
> >>> add .targets magic? When I am trying to get x86 works, faced this issue
> >>>
> >>
> >> This solves including i386 or x86_64, but not including both at the same
> >> time. Same goes for arm vs aarch64.
> >>
> >> You can take a look at git history in target/arm, to see which kind of
> >> changes we did to make arm and aarch64 targets linkable. You'll notice
> >> most of the work was to remove (a lot of) #ifdef TARGET_X.
> >
> > See it
> > SHA-1: ec7e5a90fea996f04ea24e81b680a87bc975354a
> > * target/arm: Remove TYPE_AARCH64_CPU
> >
> > So I am just doing just the reverse direction, I am fixes x86_64 in a way
> > that
> > register both "x86_64-cpu" "i386-cpu" variants, though this way seems
> > more suitable
> > for your heterogeneous emulation, but we need to register
> > everything(CPUs) twice.
>
> We'll have to register this twice anyway for heterogeneous, I don't see
> any other solution to have both accessible at the same time. That said,
> we are not yet there, and current patch solves the actual problem of
> having QOM types registered twice.
>
> I'll let Peter say what he thinks about this.
Hi Peter, what's your suggest about this?
>
> Regards,
> Pierrick
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
