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 <[email protected]>
---
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