Re: [PATCH] hw/arm/smmu: add memory regions as property for an SMMU instance

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

On Fri, 12 Dec 2025 at 06:16, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> Hi Pierrick,
>
> On 11/12/25 23:17, Pierrick Bouvier wrote:
> > This will be used to access non-secure and secure memory. Secure support
> > and Granule Protection Check (for RME) for SMMU need to access secure
> > memory.
>
> Sorry yesterday it was late for me and I forgot to post the similar
> patch :/
>
> >
> > As well, it allows to remove usage of global address_space_memory,
> > allowing different SMMU instances to have a specific view of memory.
> >
> > Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> > ---
> >   include/hw/arm/smmu-common.h |  4 ++++
> >   hw/arm/sbsa-ref.c            | 16 ++++++++++++----
> >   hw/arm/smmu-common.c         | 24 ++++++++++++++++++++++++
> >   hw/arm/virt.c                | 16 +++++++++++-----
> >   4 files changed, 51 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/hw/arm/smmu-common.h b/include/hw/arm/smmu-common.h
> > index a6bdb67a983..0f08ae080c9 100644
> > --- a/include/hw/arm/smmu-common.h
> > +++ b/include/hw/arm/smmu-common.h
> > @@ -227,6 +227,10 @@ struct SMMUState {
> >       uint8_t bus_num;
> >       PCIBus *primary_bus;
> >       bool smmu_per_bus; /* SMMU is specific to the primary_bus */
> > +    MemoryRegion *memory;
> > +    AddressSpace as_memory;
> > +    MemoryRegion *secure_memory;
> > +    AddressSpace as_secure_memory;
>
> Has SMMU concept of "secure memory"?

Yes -- IHI0070G.b section 3.10.2: when SMMU_S_IDR1.SECURE_IMPL=1
"the SMMU can generate transactions to the memory system, to Secure
PA space (NS=0) and Non-secure PA space (NS=1)".

When the SMMU has Realm support then further (3.10.3)
the output PA space can be Realm, and also GPT checks are
always done to the Root address space.

So an SMMU with Secure and Realm support can emit transactions
to any of the 4 address spaces, the same as a CPU with those
features.

Separately from that, at the moment the way we model Realm
and Root is by using the same QEMU MemoryRegion trees we
have for NS and S and just using MemTxAttrs::space to distinguish,
because we don't have any need for devices that appear only in
Realm and not NS, or only in Root and not S. So for CPUs we
collapse the 4 architectural address spaces down into two QEMU
ones.

For the SMMU we can presumably follow the CPU there
(with an equivalent "give me the AddressSpace I should
use for these MemTxAttrs" function as arm_addressspace()).

> My understanding is just a
> different memory to access GPT, so I'd name it "gpt_memory".

I would prefer that we use the architecturally standard
terminology here.

thanks
-- PMM