Re: [Qemu-devel] [RFC] Memory API

[Peter Maydell <peter.maydell@linaro.org>]

On 19 May 2011 10:24, Edgar E. Iglesias <edgar.iglesias@gmail.com> wrote:
> On the CPU local aspect, I think it is increasingly common in the
> embedded space to see local busses with CPU local peripherals in
> addition to the "system" bus with "global" peripherals.

Yes: newer ARM cores have per-CPU builtin peripherals (timers
and the like). The interrupt controller also typically has some
registers which are per-CPU and some which are global. At the
moment these are rather weirdly placed outside the CPU and it's
the obligation of the board model to instantiate them.

(Cache modelling would also require a bit more care about the
distinction between which core made a memory request and where
per-core peripherals live in the cache hierarchy.)

The other sort-of-per-core thing is that for TrustZone (which
we don't currently support but might want to) if a core is in
'secure' mode it can potentially see a completely different memory
map. [In hardware this works by the secure/nonsecure bit being
passed around with memory transactions and devices or fabric
behaving differently depending on its value.]

It would also be nice if the APIs supported more heterogenous setups
(for instance a VersatileExpress model where we model a quad
core A9 main CPU and also the M3 microcontroller that does
system control and has a completely different view of the world.)

> Another thing that was discussed was the ability for devices to know
> who is accessing them, I think this is uncommon but still it does
> exist.

Yes, again the ARM GIC is an example. At the momemnt this is
implemented by the GIC implementation looking at
cpu_single_env->cpu_index.

Debug setups also sometimes have magic peripherals that behave
differently depending on who is accessing them.

-- PMM