[RFC 0/1] hw/pci: Add sec-sid property to PCIDevice

[RFC 0/1] hw/pci: Add sec-sid property to PCIDevice

[Tao Tang]

Hi all,

this short series adds a small but important hook to PCIDevice: a
system-defined StreamID Security State (SEC_SID) field and QOM property,
intended to be used by the Arm SMMUv3 model.

One point I want to stress up front: I am fully aware that PCI/PCIe
has no architectural notion of Secure vs Non-secure. The PCIe
specification does not define a "security state" for PCIe functions, and
this patch is **not** trying to introduce such a concept or to model a
"Secure PCIe device" in the PCIe sense.

Instead, this change is driven purely by the Arm SMMU architecture.

In SMMUv3, when a device issues a DMA request, the request carries the
device's SEC_SID attribute to the SMMU. The SMMU then uses SEC_SID to
determine how to interpret the security state of that transaction:

  * If SEC_SID=Secure, the SMMU examines additional signals to decide
    whether this particular request is a Secure stream or a Non-secure
    stream.
  * If SEC_SID=Non-secure, the SMMU always treats the request as a
    Non-secure stream, regardless of any other signals.

In other words, SEC_SID=Non-secure restricts a device to Non-secure
streams only, while SEC_SID=Secure allows the SMMU to consider both
possibilities on a per-transaction basis.

The SMMU specification explicitly states that the association between
a device and its SEC_SID is a *system-defined property*. As Arm
experts have clarified during the Secure SMMU review process [1], if a
device is capable of issuing requests with SEC_SID=Secure, the system
typically applies a static marker to that device—this is precisely why
this patch proposes a static SEC_SID property for PCIe devices.

[1] https://lore.kernel.org/qemu-devel/4870b7df-4cb3-457e-9a18-87f3558adf09@linaro.org/

From QEMU's point of view, the platform needs a place to store this
attribute for each PCI function. The Secure SMMU series already
plumbs SEC_SID through the SMMUv3 internals. What is missing on the
PCI side is a simple way for the board to attach this system-defined
SEC_SID to a PCI function. This is exactly what this patch provides.

Concretely, the patch adds:

  * a `uint8_t sec_sid` field to `struct PCIDevice`; and
  * a `"sec-sid"` QOM property in `hw/pci/pci.c`.

The semantics are:

  * `sec_sid` is **not** a PCIe architectural attribute and is **not**
    visible to the guest as part of PCIe configuration space.
  * It is a system-defined attribute carried with each DMA request
    from the device to the SMMU, controlling how the SMMU interprets
    the security state of transactions:
      - SEC_SID=0 (Non-secure): all requests are treated as
        Non-secure streams
      - SEC_SID=1 (Secure): the SMMU examines per-transaction signals
        to determine Secure vs Non-secure
  * This is a static property set at device initialization, not a
    per-transaction field modified by software.
  * The default is 0, so existing machines and devices are unchanged
    unless they explicitly set `"sec-sid"`.

The idea is that board code (or test setups) can configure the SEC_SID
for specific devices, thereby controlling whether the SMMU will always
treat their transactions as Non-secure (SEC_SID=0) or whether it will
examine additional signals to distinguish Secure vs Non-secure streams
(SEC_SID=1). The PCIe protocol itself remains untouched: we are not
reinterpreting any PCIe capability or config bit as a security state,
and we are not changing how PCIe transactions are generated or routed.

Looking ahead to Arm RME-DA / TDISP modelling, the expectation is that
Realm vs Non-secure device assignment will be driven by the TDISP/DTI
protocol, in line with Arm’s guidance that DTI-ATS covers Non-secure and
Realm streams and that PCIe StreamIDs must not be used to grant Secure
privileges. In that context, we do not plan to represent Realm or
"Secure PCIe endpoints" via this static field; `"sec-sid"` remains an
Arm SMMU integration hook rather than a PCIe security model.

Feedback is very welcome on whether PCIDevice is the right place to host
this SMMU-oriented, system-defined SEC_SID, and whether the separation
between "PCIe has no security state" and "SMMU needs a security identity
for its clients" is clear enough.

Tao Tang (1):
  hw/pci: Add sec-sid property to PCIDevice

 hw/pci/pci.c                | 7 +++++++
 include/hw/pci/pci_device.h | 3 +++
 2 files changed, 10 insertions(+)

-- 
2.34.1

[RFC 1/1] hw/pci: Add sec-sid property to PCIDevice

[Tao Tang]

Arm SMMUv3 uses SEC_SID to control how it interprets the security
state of incoming DMA requests. When SEC_SID=Secure, the SMMU
examines additional signals to distinguish Secure vs Non-secure
streams; when SEC_SID=Non-secure, all requests are treated as
Non-secure streams regardless of other signals.

The SMMU spec states that SEC_SID is a system-defined property.
And devices capable of SEC_SID=Secure should be statically marked
by the system.

This adds a uint8_t sec_sid field and "sec-sid" QOM property to
PCIDevice, allowing boards to configure this attribute. Values are
0 (Non-secure, default) and 1 (Secure).

Note: This is not a PCIe architectural feature. It is purely an
SMMU integration mechanism and does not affect PCIe transactions.

Future RME-DA/TDISP work will use the PCIe TDISP/DTI protocol to model
Realm and Non-secure streams, instead of extending this static field.

Signed-off-by: Tao Tang <tangtao1634@phytium.com.cn>
---
 hw/pci/pci.c                | 7 +++++++
 include/hw/pci/pci_device.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index b1eba348e0..1f944d0e39 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -98,6 +98,13 @@ static const Property pci_props[] = {
     DEFINE_PROP_STRING("sriov-pf", PCIDevice, sriov_pf),
     DEFINE_PROP_BIT("x-pcie-ext-tag", PCIDevice, cap_present,
                     QEMU_PCIE_EXT_TAG_BITNR, true),
+
+    /*
+     * System-defined, statically configured SEC_SID for this PCI device, used
+     * by Arm SMMU. Currently only support Non-secure (0) and Secure (1)
+     * security states.
+     */
+    DEFINE_PROP_UINT8("sec-sid", PCIDevice, sec_sid, 0),
     { .name = "busnr", .info = &prop_pci_busnr },
 };
 
diff --git a/include/hw/pci/pci_device.h b/include/hw/pci/pci_device.h
index 88ccea5011..16364731da 100644
--- a/include/hw/pci/pci_device.h
+++ b/include/hw/pci/pci_device.h
@@ -184,6 +184,9 @@ struct PCIDevice {
     uint32_t max_bounce_buffer_size;
 
     char *sriov_pf;
+
+    /* Arm SMMU SEC_SID */
+    uint8_t sec_sid;
 };
 
 static inline int pci_intx(PCIDevice *pci_dev)
-- 
2.34.1

Re: [RFC 1/1] hw/pci: Add sec-sid property to PCIDevice

[Pierrick Bouvier]

Hi Tao,

On 12/11/25 2:27 AM, Tao Tang wrote:
> Arm SMMUv3 uses SEC_SID to control how it interprets the security
> state of incoming DMA requests. When SEC_SID=Secure, the SMMU
> examines additional signals to distinguish Secure vs Non-secure
> streams; when SEC_SID=Non-secure, all requests are treated as
> Non-secure streams regardless of other signals.
> 
> The SMMU spec states that SEC_SID is a system-defined property.
> And devices capable of SEC_SID=Secure should be statically marked
> by the system.
> 
> This adds a uint8_t sec_sid field and "sec-sid" QOM property to
> PCIDevice, allowing boards to configure this attribute. Values are
> 0 (Non-secure, default) and 1 (Secure).
> 
> Note: This is not a PCIe architectural feature. It is purely an
> SMMU integration mechanism and does not affect PCIe transactions.
> 
> Future RME-DA/TDISP work will use the PCIe TDISP/DTI protocol to model
> Realm and Non-secure streams, instead of extending this static field.
> 
> Signed-off-by: Tao Tang <tangtao1634@phytium.com.cn>
> ---
>   hw/pci/pci.c                | 7 +++++++
>   include/hw/pci/pci_device.h | 3 +++
>   2 files changed, 10 insertions(+)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index b1eba348e0..1f944d0e39 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -98,6 +98,13 @@ static const Property pci_props[] = {
>       DEFINE_PROP_STRING("sriov-pf", PCIDevice, sriov_pf),
>       DEFINE_PROP_BIT("x-pcie-ext-tag", PCIDevice, cap_present,
>                       QEMU_PCIE_EXT_TAG_BITNR, true),
> +
> +    /*
> +     * System-defined, statically configured SEC_SID for this PCI device, used
> +     * by Arm SMMU. Currently only support Non-secure (0) and Secure (1)
> +     * security states.
> +     */
> +    DEFINE_PROP_UINT8("sec-sid", PCIDevice, sec_sid, 0),
>       { .name = "busnr", .info = &prop_pci_busnr },
>   };
>   
> diff --git a/include/hw/pci/pci_device.h b/include/hw/pci/pci_device.h
> index 88ccea5011..16364731da 100644
> --- a/include/hw/pci/pci_device.h
> +++ b/include/hw/pci/pci_device.h
> @@ -184,6 +184,9 @@ struct PCIDevice {
>       uint32_t max_bounce_buffer_size;
>   
>       char *sriov_pf;
> +
> +    /* Arm SMMU SEC_SID */
> +    uint8_t sec_sid;
>   };
>   
>   static inline int pci_intx(PCIDevice *pci_dev)

this is an excellent addition, and something we definitely need for 
Secure support in SMMU.

May I suggest we have a string value instead of a uint8_t?

This way, it would be explicit to have:
sec-sid=non-secure (default)
sec-sid=secure
It can be backed by a proper SMMUSecSID variable, so once command line 
is parsed, we don't deal with string anymore, but with a proper enum 
instead.

Thanks,
Pierrick