> -----Original Message-----
> From: Philippe Mathieu-Daudé <phi...@linaro.org>
> Sent: Wednesday, March 12, 2025 6:40 PM
> To: Brian Cain <brian.c...@oss.qualcomm.com>; qemu-devel@nongnu.org
> Cc: richard.hender...@linaro.org; quic_mathb...@quicinc.com;
> a...@rev.ng; a...@rev.ng; quic_mlie...@quicinc.com;
> ltaylorsimp...@gmail.com; alex.ben...@linaro.org;
> quic_mbur...@quicinc.com; sidn...@quicinc.com; Brian Cain
> <bc...@quicinc.com>
> Subject: Re: [PATCH 28/38] target/hexagon: Initialize htid, modectl regs
>
> On 13/3/25 00:10, Brian Cain wrote:
> >
> > On 3/12/2025 2:19 PM, Philippe Mathieu-Daudé wrote:
> >> On 1/3/25 06:26, Brian Cain wrote:
> >>> From: Brian Cain <bc...@quicinc.com>
> >>>
> >>> Signed-off-by: Brian Cain <brian.c...@oss.qualcomm.com>
> >>> ---
> >>> target/hexagon/cpu.c | 8 ++++++++
> >>> 1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/target/hexagon/cpu.c b/target/hexagon/cpu.c index
> >>> 36a93cc22f..2b6a707fca 100644
> >>> --- a/target/hexagon/cpu.c
> >>> +++ b/target/hexagon/cpu.c
> >>> @@ -26,6 +26,7 @@
> >>> #include "fpu/softfloat-helpers.h"
> >>> #include "tcg/tcg.h"
> >>> #include "exec/gdbstub.h"
> >>> +#include "cpu_helper.h"
> >>> static void hexagon_v66_cpu_init(Object *obj) { }
> >>> static void hexagon_v67_cpu_init(Object *obj) { } @@ -290,11
> >>> +291,18 @@ static void hexagon_cpu_reset_hold(Object *obj,
> ResetType
> >>> type)
> >>> set_float_default_nan_pattern(0b11111111, &env->fp_status);
> >>> #ifndef CONFIG_USER_ONLY
> >>> + HexagonCPU *cpu = HEXAGON_CPU(cs);
> >>> +
> >>> if (cs->cpu_index == 0) {
> >>
> >> This doesn't scale to heterogeneous emulation.
> >>
> >
> > If we have a target-specific index here (instead of cpu_index)
> > guarding the "g_sreg" allocation shared by these Hexagon vCPUs, does
> > that suffice? Or is the problem the shared allocation itself?
>
> I'm not sure that suffices, but it is still better from my PoV.
>
> Let's assume we instantiate 4 ARM cores, then 2 HEX ones. The first Hexagon
> core has cpu_index=5. Now for the same example machine we instantiate
> first the Hexagon cores, then the ARM ones. The first Hexagon core has
> cpu_index=0.
>
> > Could a heterogeneous emulation configuration consist of multiple
> > instances of (same-architecture) vCPU-groups?
>
> Up to you if you want to model multiple hexagon SoCs in the same machine
> ;) Note in that case you could use a CPUClusterState to group.
What we are trying to model is an instance of a Hexagon that has a number of
threads and some resources that are shared. The shared resources include the
TLB and global S registers. The initial thought was to tie the shared
resources to the thread with cpu_index == 0. If we were to model a Qualcomm
SoC, there would be multiple ARM cores and multiple Hexagon instances. Each
Hexagon instance would have distinct shared resources. So, you are correct
that using cpu_index is not going to scale.
What is the recommended way to model this? I see a "nr_threads" field in
CPUCore but no clear way to find the threads. PPC has some cores that add a
"threads" field. Should we follow this approach?
HTH,
Taylor
