From: Pierrick Bouvier <pierrick.bouvier@linaro.org>
To: Tao Tang <tangtao1634@phytium.com.cn>,
Eric Auger <eric.auger@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org,
"Chen Baozi" <chenbaozi@phytium.com.cn>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Jean-Philippe Brucker" <jean-philippe@linaro.org>,
"Mostafa Saleh" <smostafa@google.com>,
"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: [RFC v3 08/21] hw/arm/smmuv3: Add separate address space for secure SMMU accesses
Date: Thu, 11 Dec 2025 14:19:44 -0800 [thread overview]
Message-ID: <d51f1433-ee70-4bb8-bebf-e348008460eb@linaro.org> (raw)
In-Reply-To: <db7fde79-85fa-4bd4-83ca-021ed3f09353@linaro.org>
On 12/11/25 2:12 PM, Pierrick Bouvier wrote:
> Hi Tao,
>
> On 10/12/25 8:06 AM, Tao Tang wrote:
>> According to the Arm architecture, SMMU-originated memory accesses,
>> such as fetching commands or writing events for a secure stream, must
>> target the Secure Physical Address (PA) space. The existing model sends
>> all DMA to the global non-secure address_space_memory.
>>
>> This patch introduces the infrastructure to differentiate between secure
>> and non-secure memory accesses. Firstly, SMMU_SEC_SID_S is added in
>> SMMUSecSID enum to represent the secure context. Then a weak global
>> symbol, arm_secure_address_space, is added, which can be provided by the
>> machine model to represent the Secure PA space.
>>
>> A new helper, smmu_get_address_space(), selects the target address
>> space based on SEC_SID. All internal DMA calls
>> (dma_memory_read/write) will be updated to use this helper in follow-up
>> patches.
>>
>> Signed-off-by: Tao Tang <tangtao1634@phytium.com.cn>
>> ---
>> hw/arm/smmu-common.c | 8 ++++++++
>> hw/arm/virt.c | 5 +++++
>> include/hw/arm/smmu-common.h | 27 +++++++++++++++++++++++++++
>> 3 files changed, 40 insertions(+)
>>
>> diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
>> index 62a7612184..24db448683 100644
>> --- a/hw/arm/smmu-common.c
>> +++ b/hw/arm/smmu-common.c
>> @@ -30,6 +30,14 @@
>> #include "hw/arm/smmu-common.h"
>> #include "smmu-internal.h"
>>
>> +/* Global state for secure address space availability */
>> +bool arm_secure_as_available;
>> +
>> +void smmu_enable_secure_address_space(void)
>> +{
>> + arm_secure_as_available = true;
>> +}
>> +
>> /* IOTLB Management */
>>
>> static guint smmu_iotlb_key_hash(gconstpointer v)
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 175023897a..83dc62a095 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -92,6 +92,8 @@
>> #include "hw/cxl/cxl_host.h"
>> #include "qemu/guest-random.h"
>>
>> +AddressSpace arm_secure_address_space;
>> +
>> static GlobalProperty arm_virt_compat[] = {
>> { TYPE_VIRTIO_IOMMU_PCI, "aw-bits", "48" },
>> };
>> @@ -2257,6 +2259,9 @@ static void machvirt_init(MachineState *machine)
>> memory_region_init(secure_sysmem, OBJECT(machine), "secure-memory",
>> UINT64_MAX);
>> memory_region_add_subregion_overlap(secure_sysmem, 0, sysmem, -1);
>> + address_space_init(&arm_secure_address_space, secure_sysmem,
>> + "secure-memory-space");
>> + smmu_enable_secure_address_space();
>> }
>>
>> firmware_loaded = virt_firmware_init(vms, sysmem,
>> diff --git a/include/hw/arm/smmu-common.h b/include/hw/arm/smmu-common.h
>> index b0dae18a62..d54558f94b 100644
>> --- a/include/hw/arm/smmu-common.h
>> +++ b/include/hw/arm/smmu-common.h
>> @@ -43,9 +43,36 @@
>> /* StreamID Security state */
>> typedef enum SMMUSecSID {
>> SMMU_SEC_SID_NS = 0,
>> + SMMU_SEC_SID_S,
>> SMMU_SEC_SID_NUM,
>> } SMMUSecSID;
>>
>> +extern AddressSpace __attribute__((weak)) arm_secure_address_space;
>> +extern bool arm_secure_as_available;
>> +void smmu_enable_secure_address_space(void);
>> +
>> +/*
>> + * Return the address space corresponding to the SEC_SID.
>> + * If SEC_SID is Secure, but secure address space is not available,
>> + * return NULL and print a warning message.
>> + */
>> +static inline AddressSpace *smmu_get_address_space(SMMUSecSID sec_sid)
>> +{
>> + switch (sec_sid) {
>> + case SMMU_SEC_SID_NS:
>> + return &address_space_memory;
>> + case SMMU_SEC_SID_S:
>> + if (!arm_secure_as_available || arm_secure_address_space.root == NULL) {
>> + printf("Secure address space requested but not available");
>> + return NULL;
>> + }
>> + return &arm_secure_address_space;
>> + default:
>> + printf("Unknown SEC_SID value %d", sec_sid);
>> + return NULL;
>> + }
>> +}
>> +
>> /*
>> * Page table walk error types
>> */
>
> I ran into the same issue, when adding Granule Protection Check to the
> SMMU, for RME support. It requires access to secure memory, where
> Granule Protection Table is kept, and thus, access secure address space.
>
> After talking with Richard and Philippe, I have been suggested a better
> way. Similar to how arm cpus handle this, boards (virt & sbsa-ref) are
> simply passing pointers to MemoryRegion for global and secure memory.
> Then, the SMMU can create its own address spaces, based on those regions.
>
> It's clean, does not require any weak variable, and mimic what is
> already done for cpus. Please see the two patches attached.
>
> First one define properties, and pass memory regions from boards to
> SMMU. Second one replace global address spaces with SMMU ones.
>
> I'll send patch 1 as it's own series, and you can take inspiration from
> patch 2 for this series. SMMU unit tests will need to be modified to be
> passed the memory regions also.
>
> Regards,
> Pierrick
Sent patch 1 here:
https://lore.kernel.org/qemu-devel/20251211221715.2206662-1-pierrick.bouvier@linaro.org/T/#u
next prev parent reply other threads:[~2025-12-11 22:20 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-12 15:06 [RFC v3 00/21] hw/arm/smmuv3: Add initial support for Secure State Tao Tang
2025-10-12 15:06 ` [RFC v3 01/21] hw/arm/smmuv3: Fix incorrect reserved mask for SMMU CR0 register Tao Tang
2025-10-12 15:06 ` [RFC v3 02/21] hw/arm/smmuv3: Correct SMMUEN field name in CR0 Tao Tang
2025-10-12 15:06 ` [RFC v3 03/21] hw/arm/smmuv3: Introduce secure registers Tao Tang
2025-11-21 12:47 ` Eric Auger
2025-10-12 15:06 ` [RFC v3 04/21] refactor: Move ARMSecuritySpace to a common header Tao Tang
2025-11-21 12:49 ` Eric Auger
2025-10-12 15:06 ` [RFC v3 05/21] hw/arm/smmuv3: Introduce banked registers for SMMUv3 state Tao Tang
2025-11-21 13:02 ` Eric Auger
2025-11-23 9:28 ` [RESEND RFC " Tao Tang
2025-10-12 15:06 ` [RFC v3 06/21] hw/arm/smmuv3: Thread SEC_SID through helper APIs Tao Tang
2025-11-21 13:13 ` Eric Auger
2025-10-12 15:06 ` [RFC v3 07/21] hw/arm/smmuv3: Track SEC_SID in configs and events Tao Tang
2025-12-02 11:05 ` Eric Auger
2025-10-12 15:06 ` [RFC v3 08/21] hw/arm/smmuv3: Add separate address space for secure SMMU accesses Tao Tang
2025-12-02 13:53 ` Eric Auger
2025-12-03 13:50 ` Tao Tang
2025-12-11 22:12 ` Pierrick Bouvier
2025-12-11 22:19 ` Pierrick Bouvier [this message]
2025-10-12 15:06 ` [RFC v3 09/21] hw/arm/smmuv3: Plumb transaction attributes into config helpers Tao Tang
2025-12-02 14:03 ` Eric Auger
2025-12-03 14:03 ` Tao Tang
2025-10-12 15:06 ` [RFC v3 10/21] hw/arm/smmu-common: Key configuration cache on SMMUDevice and SEC_SID Tao Tang
2025-12-02 14:18 ` Eric Auger
2025-10-12 15:06 ` [RFC v3 11/21] hw/arm/smmuv3: Decode security attributes from descriptors Tao Tang
2025-12-02 15:19 ` Eric Auger
2025-12-03 14:30 ` Tao Tang
2025-10-12 15:12 ` [RFC v3 12/21] hw/arm/smmu-common: Implement secure state handling in ptw Tao Tang
2025-12-02 15:53 ` Eric Auger
2025-12-03 15:10 ` Tao Tang
2025-10-12 15:12 ` [RFC v3 13/21] hw/arm/smmuv3: Tag IOTLB cache keys with SEC_SID Tao Tang
2025-12-02 16:08 ` Eric Auger
2025-12-03 15:28 ` Tao Tang
2025-10-12 15:13 ` [RFC v3 14/21] hw/arm/smmuv3: Add access checks for MMIO registers Tao Tang
2025-12-02 16:31 ` Eric Auger
2025-12-03 15:32 ` Tao Tang
2025-10-12 15:13 ` [RFC v3 15/21] hw/arm/smmuv3: Determine register bank from MMIO offset Tao Tang
2025-10-14 23:31 ` Pierrick Bouvier
2025-12-04 14:21 ` Eric Auger
2025-12-05 6:31 ` Tao Tang
2025-10-12 15:13 ` [RFC v3 16/21] hw/arm/smmuv3: Implement SMMU_S_INIT register Tao Tang
2025-12-04 14:33 ` Eric Auger
2025-12-05 8:23 ` Tao Tang
2025-10-12 15:14 ` [RFC v3 17/21] hw/arm/smmuv3: Pass security state to command queue and IRQ logic Tao Tang
2025-12-04 14:46 ` Eric Auger
2025-12-05 9:42 ` Tao Tang
2025-10-12 15:14 ` [RFC v3 18/21] hw/arm/smmuv3: Harden security checks in MMIO handlers Tao Tang
2025-12-04 14:59 ` Eric Auger
2025-12-05 10:36 ` Tao Tang
2025-12-05 17:23 ` Pierrick Bouvier
2025-10-12 15:15 ` [RFC v3 19/21] hw/arm/smmuv3: Use iommu_index to represent the security context Tao Tang
2025-10-15 0:02 ` Pierrick Bouvier
2025-10-16 6:37 ` Tao Tang
2025-10-16 7:04 ` Pierrick Bouvier
2025-10-20 8:44 ` Tao Tang
2025-10-20 22:55 ` Pierrick Bouvier
2025-10-21 3:51 ` Tao Tang
2025-10-22 21:23 ` Pierrick Bouvier
2025-10-23 9:02 ` Tao Tang
2025-12-04 15:05 ` Eric Auger
2025-12-05 10:54 ` Tao Tang
2025-10-12 15:15 ` [RFC v3 20/21] hw/arm/smmuv3: Initialize the secure register bank Tao Tang
2025-12-02 16:36 ` Eric Auger
2025-12-03 15:48 ` Tao Tang
2025-10-12 15:16 ` [RFC v3 21/21] hw/arm/smmuv3: Add secure migration and enable secure state Tao Tang
2025-12-02 16:39 ` Eric Auger
2025-12-03 15:54 ` Tao Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d51f1433-ee70-4bb8-bebf-e348008460eb@linaro.org \
--to=pierrick.bouvier@linaro.org \
--cc=chenbaozi@phytium.com.cn \
--cc=eric.auger@redhat.com \
--cc=jean-philippe@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=smostafa@google.com \
--cc=tangtao1634@phytium.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).