> -----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;
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. A straight assignment would work,
cpu->global_sreg = vms->g_sreg; but that isn't what you are suggesting. Can
you help me understand what I'm doing wrong.
Thanks,
> The linking would be under the control of the board model and/or the SoC
> model.
>
>
> r~
