On 3/6/26 5:30 AM, Tao Tang wrote:
Hi Eric,
On 2026/3/3 18:47, Eric Auger wrote:
On 2/21/26 11:19 AM, Tao Tang wrote:
Parse each PCI device's sec-sid property during SMMU device initialization
and cache it in SMMUDevice::sec_sid. Support "non-secure" and "secure",
default to non-secure when unspecified, and reject invalid values with an
explicit error. Use sdev->sec_sid in smmuv3_translate() to select the
register bank instead of hardcoding the non-secure context.
Keep sec-sid parsing in smmu-common, and add a SMMUv3-specific validation
hook to enforce architectural constraints: fail fast when sec-sid=secure
while SMMU_S_IDR1.SECURE_IMPL is 0 or secure AS is not available.
Typically, SEC_SID is a system-defined attribute (e.g. sideband or tied-off)
rather than something a PCIe endpoint can freely toggle in pre-RME scenario.
So this PCI sec-sid property is used as a static platform/testing knob to
drive the SMMU bank selection.
For future RME-DA + TDISP, this will need to become dynamic: the effective
state for PCIe requests is derived from PCIe IDE/TDISP T/XT
(e.g. SEC_SID = (XT || T) ? Realm : Non-secure), so we'll switch from a
static property to a runtime per-device state update when that plumbing
is added.
When a translation is triggered, address_space_translate_iommu passes attrs.
MemTxAttrs.secure bit should tell you whether the translation is
requested in secure mode.
Shouldn't we pass that information the smmuv3 translate function()?
In address_space_translate_iommu I see:
if (imrc->attrs_to_index) {
iommu_idx = imrc->attrs_to_index(iommu_mr, attrs);
}
iotlb = imrc->translate(iommu_mr, addr, is_write ?
IOMMU_WO : IOMMU_RO, iommu_idx);
Thanks for pointing this out.
I agree that per-transaction request intent should eventually come from
MemTxAttrs or attrs_to_index().
However, the current producer side is not yet in a state where
transaction attrs alone can replace stream-level security wiring: many
PCI DMA paths still use MEMTXATTRS_UNSPECIFIED, and space cannot be
consumed safely without an explicit validity signal. For example, an
incorrect zero-initialized or otherwise unspecified .space value cannot
be treated as authoritative by itself as Pierrick mentioned in this thread:
https://lore.kernel.org/qemu-devel/[email protected]/
In the current codebase, this can easily blur the distinction between
“explicitly Secure” and “not specified at all”, especially for legacy or
non-Arm-aware producers. So I think there are really two separate
concerns here:
1. the per-transaction intent (which should indeed come from MemTxAttrs
/ attrs_to_index()); and
2. the stream-level capability / wiring, i.e. whether this SID is
allowed to reach the Secure programming interface in the first place.
My concern with the current patch is not that attrs-based routing is the
wrong long-term direction, but that today transaction attrs are not yet
propagated consistently enough to replace a stream-level model entirely.
So for now, I think a static sec-sid property is still useful as a
platform knob, until producer-side propagation becomes reliable enough.
Once that is in place, I agree that the bank selection should ultimately
be driven through the standard per-transaction attrs path. How do you
think about it?
As a complement of information, SMMU specification mentions:
```
3.10.1 StreamID Security state (SEC_SID)
Note: Whether a stream is under Secure control or not is a different
property to the target PA space of a transaction.
```
At the time, we checked with spec authors at Arm what was the exact
meaning, and they confirmed it was a builtin (static) property of the
system. A secure device will always be secure through execution.
Realms have a different approach, and PCI transport has the T bit for
that, to make it a dynamic property.
Of course, we can implement things differently than what spec says, but
I definitely see it as a design hint that it should be a property of the
device, and not of the transaction itself.
My 2 cents,
Pierrick
