On Thu, Jun 20, 2024 at 12:25:51PM +0200, Philippe Mathieu-Daudé wrote:
> On 20/6/24 12:10, Peter Maydell wrote:
> > On Tue, 18 Jun 2024 at 15:51, Philippe Mathieu-Daudé <phi...@linaro.org>
> > wrote:
> > >
> > > On 18/6/24 16:40, Zheyu Ma wrote:
> > > > This commit updates the a9_gtimer_get_current_cpu() function to handle
> > > > cases where QTest is enabled. When QTest is used, it returns 0 instead
> > > > of dereferencing the current_cpu, which can be NULL. This prevents the
> > > > program from crashing during QTest runs.
> > > >
> > > > Reproducer:
> > > > cat << EOF | qemu-system-aarch64 -display \
> > > > none -machine accel=qtest, -m 512M -machine npcm750-evb -qtest stdio
> > > > writel 0xf03fe20c 0x26d7468c
> > > > EOF
> > > >
> > > > Signed-off-by: Zheyu Ma <zheyum...@gmail.com>
> > > > ---
> > > > hw/timer/a9gtimer.c | 5 +++++
> > > > 1 file changed, 5 insertions(+)
>
>
> > > > if (current_cpu->cpu_index >= s->num_cpu) {
> > >
> > > That said, such accesses of @current_cpu from hw/ are dubious.
> >
> > True, but I'm not sure we ever settled on the right way to avoid
> > them, did we?
>
> No we didn't, it is still in my TODO list; we might discuss it
> when I post my RFC.
>
Yeah, this way of getting the core id is a problem when having multiple
ARM CPU subsystems (and for heterogenous cores).
IIRC, when I looked at what the GIC v2 HW does, the GIC exposes an AMBA
port for each CPU. In my mental model that would translate to exposing
multiple Memory Reginos (sysbus_init_mmio) and mapping the appropriate
device MR to each CPU AddressSpace.
We could also do it with memory attributes but I don't think the
master Ids are standardised enough to extract a core-index from
with out having SoC specific code,, at least not accross Xilinx devices.
I never looked at newer GIC versions nor the mmio mapped timers
though...
Cheers,
Edgar
