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.
