RE: [PATCH 28/38] target/hexagon: Initialize htid, modectl regs

[<ltaylorsimpson@gmail.com>]

> -----Original Message-----
> From: Philippe Mathieu-Daudé <philmd@linaro.org>
> Sent: Wednesday, March 12, 2025 6:40 PM
> To: Brian Cain <brian.cain@oss.qualcomm.com>; qemu-devel@nongnu.org
> Cc: richard.henderson@linaro.org; quic_mathbern@quicinc.com;
> ale@rev.ng; anjo@rev.ng; quic_mliebel@quicinc.com;
> ltaylorsimpson@gmail.com; alex.bennee@linaro.org;
> quic_mburton@quicinc.com; sidneym@quicinc.com; Brian Cain
> <bcain@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 <bcain@quicinc.com>
> >>>
> >>> Signed-off-by: Brian Cain <brian.cain@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