On 3/19/25 09:08, Sid Manning wrote:
-----Original Message-----
From: Richard Henderson <richard.hender...@linaro.org>
Sent: Thursday, March 13, 2025 2:07 PM
To: ltaylorsimp...@gmail.com; 'Philippe Mathieu-Daudé'
<phi...@linaro.org>; 'Brian Cain' <brian.c...@oss.qualcomm.com>; qemu-
de...@nongnu.org
Cc: Matheus Bernardino (QUIC) <quic_mathb...@quicinc.com>;
a...@rev.ng; a...@rev.ng; Marco Liebel (QUIC)
<quic_mlie...@quicinc.com>; alex.ben...@linaro.org; Mark Burton (QUIC)
<quic_mbur...@quicinc.com>; Sid Manning <sidn...@quicinc.com>; Brian
Cain <bc...@quicinc.com>
Subject: Re: [PATCH 28/38] target/hexagon: Initialize htid, modectl regs
WARNING: This email originated from outside of Qualcomm. Please be wary
of any links or attachments, and do not enable macros.
On 3/13/25 11:47, ltaylorsimp...@gmail.com wrote:
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?
I recommend that the shared resources be modeled as a separate Object,
which is linked via object_property_add_link to all of the cpus that use it.
[Sid Manning]
Hi Richard,
An example of shared resources would be the system registers. They are broken
down into 2 regions. Each thread has its own copy of system registers 0-15
while registers 16-63 are global. Right now CPUHexagonState contains a
pointer, g_sreg which points back to cpu[0]'s state thus keeping one copy of
the global registers, accesses are done with BQL held to avoid race conditions.
Your suggestion is to create a new object to represent the set of global system
registers, I tried this:
#define TYPE_HEXAGON_G_SREG "hexagon.global_sreg"
OBJECT_DECLARE_SIMPLE_TYPE(HexagonGlobalSREGState, HEXAGON_G_SREG)
struct HexagonGlobalSREGState {
SysBusDevice parent_obj;
SysBusDevice is more than you need -- Object is sufficient here.
uint32_t regs[64];
};
In our virtual machine init:
vms->g_sreg = HEXAGON_G_SREG(qdev_new(TYPE_HEXAGON_G_SREG));
and
object_property_set_link(OBJECT(cpu), "global-sreg", OBJECT(vms->g_sreg),
&error_abort);
to attach the global regs to the cpu, but the above doesn't update cpu elements the same way calls to qdev_prop_set_uint32 will do, object_property_set_link doesn’t error out and returns true.
Did you add the DEFINE_PROP_LINK to match? I'd expect something like
DEFINE_PROP_LINK("global-sreg", HexagonCPU, g_sreg,
TYPE_HEXAGON_G_SREG, HexagonGlobalSREGState *),
Beyond that, I guess I'd have to see an actual patch to work out what's wrong.
r~
