On Fri, 12 Dec 2025 at 06:16, Philippe Mathieu-Daudé <[email protected]> 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 <[email protected]> > > --- > > 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
