On 12/12/25 2:50 AM, Peter Maydell wrote:
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.
Yes, thanks for confirming this.
I was a bit puzzled by the fact I could not read the gpt with the global
address_space_memory, but after talking with Richard and Philippe, it
made sense as this memory is under secure memory. As a consequence, I
understood better your explaination about AddressSpace in our call on
Tuesday, so that's good to see puzzle starting to get assembled.
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()).
This is exactly what Tao introduced in his series, and that I extended
for Realm on my side.
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
Overall, I posted this as it's needed for both Tao's work and mine, and
instead of pushing this to Tao as part of this series, I thought it
could be included already, so we both can benefit without having to play
with series merging.
