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