qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@redhat.com>
To: Tao Tang <tangtao1634@phytium.com.cn>,
	Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org,
	"Chen Baozi" <chenbaozi@phytium.com.cn>,
	"Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Jean-Philippe Brucker" <jean-philippe@linaro.org>,
	"Mostafa Saleh" <smostafa@google.com>
Subject: Re: [PATCH v2 06/14] hw/arm/smmuv3: Add separate address space for secure SMMU accesses
Date: Mon, 29 Sep 2025 10:54:21 +0200	[thread overview]
Message-ID: <aaee9930-69c5-4ed1-8bc0-7ad20e084440@redhat.com> (raw)
In-Reply-To: <fcf54e8a-d4c6-49ea-b31a-35e2f5df1222@phytium.com.cn>



On 9/29/25 10:33 AM, Tao Tang wrote:
> Hi Eric,
>
> On 2025/9/29 15:44, Eric Auger wrote:
>> Hi Tao,
>>
>> On 9/25/25 6:26 PM, 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 address_space_memory.
>>>
>>> This patch introduces the infrastructure to differentiate between
>>> secure
>>> and non-secure memory accesses. 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 the is_secure context. All internal DMA calls
>>> (dma_memory_read/write) are updated to use this helper. Additionally,
>>> the attrs.secure bit is set on transactions targeting the secure
>>> address space.
>> The last sentence does not seem to be implemented in that patch?
>
>
> You are right to point this out, and my apologies for the confusion.
> As I was preparing the series, the patches were intertwined, and I
> didn't manage their boundaries clearly. This led me to mistakenly
> describe a feature in this commit message that is only implemented in
> a subsequent patch #07.
>
> I'm very sorry for the confusion and the unnecessary time this has
> cost you. In all future community interactions, I will pay special
> attention to ensuring each patch and its description are atomic and
> self-contained to reduce the review burden for everyone. Thank you for
> your guidance on this.

No problem. Your commit messages are pretty well written and we all do
such kind of oversights - at least I do ;-) -

Eric
>
>>> 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 | 20 ++++++++++++++++++++
>>>   3 files changed, 33 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 02209fadcf..805d9aadb7 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" },
>>>   };
>>> @@ -2243,6 +2245,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 3df82b83eb..cd61c5e126 100644
>>> --- a/include/hw/arm/smmu-common.h
>>> +++ b/include/hw/arm/smmu-common.h
>>> @@ -53,6 +53,26 @@ typedef enum SMMUSecurityIndex {
>>>       SMMU_SEC_IDX_NUM,
>>>   } SMMUSecurityIndex;
>>>   +extern AddressSpace __attribute__((weak)) arm_secure_address_space;
>>> +extern bool arm_secure_as_available;
>>> +void smmu_enable_secure_address_space(void);
>>> +
>>> +static inline AddressSpace
>>> *smmu_get_address_space(SMMUSecurityIndex sec_sid)
>>> +{
>>> +    switch (sec_sid) {
>>> +    case SMMU_SEC_IDX_S:
>>> +    {
>>> +        if (arm_secure_as_available) {
>>> +            return &arm_secure_address_space;
>>> +        }
>> don't you want to return NULL or at least emit an error in case
>> !arm_secure_as_available. When adding Realm support this will avoid to
>> return NS AS.
>
>
> That's a great point. Silently falling back to the non-secure address
> space is indeed dangerous. I will update the logic to return NULL and
> emit an error if the secure address space is requested but not available.
>
>>> +    }
>>> +    QEMU_FALLTHROUGH;
>>> +    case SMMU_SEC_IDX_NS:
>>> +    default:
>> Maybe return an error here in case of other value than NS
>
> Also I will change the default case to handle unexpected values by
> returning NULL, which will make the code safer for future extensions
> like Realm.  Then a check for the NULL return value at the call sites
> of smmu_get_address_space will be applied to handle the error
> appropriately in v3 series.
>
>
> Thanks again for your helpful feedback.
>
>
> Best,
>
> Tao
>
>
>>> +        return &address_space_memory;
>>> +    }
>>> +}
>>> +
>>>   /*
>>>    * Page table walk error types
>>>    */
>> Thanks
>>
>> Eric
>



  reply	other threads:[~2025-09-29  8:56 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-25 16:26 [PATCH v2 00/14] hw/arm/smmuv3: Add initial support for Secure State Tao Tang
2025-09-25 16:26 ` [PATCH v2 01/14] hw/arm/smmuv3: Fix incorrect reserved mask for SMMU CR0 register Tao Tang
2025-09-25 16:26 ` [PATCH v2 02/14] hw/arm/smmuv3: Correct SMMUEN field name in CR0 Tao Tang
2025-09-26 12:27   ` Eric Auger
2025-09-25 16:26 ` [PATCH v2 03/14] hw/arm/smmuv3: Introduce secure registers and commands Tao Tang
2025-09-27 10:29   ` Eric Auger
2025-09-28  4:46     ` Tao Tang
2025-09-25 16:26 ` [PATCH v2 04/14] refactor: Move ARMSecuritySpace to a common header Tao Tang
2025-09-28 13:19   ` Eric Auger
2025-09-25 16:26 ` [PATCH v2 05/14] hw/arm/smmuv3: Introduce banked registers for SMMUv3 state Tao Tang
2025-09-28 14:26   ` Eric Auger
2025-09-29  7:22     ` Tao Tang
2025-09-25 16:26 ` [PATCH v2 06/14] hw/arm/smmuv3: Add separate address space for secure SMMU accesses Tao Tang
2025-09-29  7:44   ` Eric Auger
2025-09-29  8:33     ` Tao Tang
2025-09-29  8:54       ` Eric Auger [this message]
2025-09-25 16:26 ` [PATCH v2 07/14] hw/arm/smmuv3: Make Configuration Cache security-state aware Tao Tang
2025-09-29  9:55   ` Eric Auger
2025-09-29 10:38     ` Tao Tang
2025-09-25 16:26 ` [PATCH v2 08/14] hw/arm/smmuv3: Add security-state handling for page table walks Tao Tang
2025-09-29 14:21   ` Eric Auger
2025-09-29 15:22     ` Tao Tang
2025-09-25 16:26 ` [PATCH v2 09/14] hw/arm/smmuv3: Add secure TLB entry management Tao Tang
2025-09-29 14:57   ` Eric Auger
2025-09-29 15:29     ` Tao Tang
2025-09-25 16:26 ` [PATCH v2 10/14] hw/arm/smmuv3: Add banked support for queues and error handling Tao Tang
2025-09-29 15:07   ` Eric Auger
2025-09-29 15:45     ` Tao Tang
2025-09-29 15:09   ` Eric Auger
2025-09-25 16:26 ` [PATCH v2 11/14] hw/arm/smmuv3: Harden security checks in MMIO handlers Tao Tang
2025-09-29 15:30   ` Eric Auger
2025-09-29 15:56     ` Tao Tang
2025-09-30 13:13       ` Eric Auger
2025-09-26  3:08 ` [PATCH v2 12/14] hw/arm/smmuv3: Use iommu_index to represent the security context Tao Tang
2025-09-26  3:08   ` [PATCH v2 13/14] hw/arm/smmuv3: Add property to enable Secure SMMU support Tao Tang
2025-09-26  3:08   ` [PATCH v2 14/14] hw/arm/smmuv3: Optional Secure bank migration via subsections Tao Tang
2025-09-29 15:33   ` [PATCH v2 12/14] hw/arm/smmuv3: Use iommu_index to represent the security context Eric Auger
2025-09-29 16:02     ` Tao Tang
2025-09-26  3:23 ` [PATCH v2 13/14] hw/arm/smmuv3: Add property to enable Secure SMMU support Tao Tang
2025-09-29 15:42   ` Eric Auger
2025-09-29 16:15     ` Tao Tang
2025-09-26  3:30 ` [PATCH v2 14/14] hw/arm/smmuv3: Optional Secure bank migration via subsections Tao Tang
2025-09-29 15:47   ` Eric Auger
2025-09-30  3:35     ` Tao Tang
2025-09-26 12:24 ` [PATCH v2 00/14] hw/arm/smmuv3: Add initial support for Secure State Eric Auger
2025-09-26 14:54   ` Tao Tang
2025-09-26 16:12     ` Eric Auger
2025-10-11  0:31 ` Pierrick Bouvier

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=aaee9930-69c5-4ed1-8bc0-7ad20e084440@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=chenbaozi@phytium.com.cn \
    --cc=jean-philippe@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=pierrick.bouvier@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.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).