On Tue, 27 Oct 2026 at 13:06, Yonggang Luo <[email protected]> wrote: > > 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?
I don't really have a preference here as I haven't been following the heterogenous work that closely. I'm happy to go with whatever Pierrick / Philippe think makes sense. -- PMM
