On 2/27/26 8:16 AM, Tao Tang wrote:
As mentioned before, should we enable it automatically in case
secure-memory address space is available at realize time?
Let me take this opportunity to address the same concern you raised
across patches #07, #17, and #30 on the secure-impl vs secure-memory topic.
My initial intent was a demand-driven (lazy) validation model — i.e.
only validate Secure capability when a device actually declares
sec-sid=secure and we go through smmu_init_sdev() /
smmuv3_validate_sec_sid(). That avoids forcing Secure-related
configuration checks on machines that never exercise Secure DMA.
That said, I agree with your point that secure-impl=on without a
corresponding secure-memory link is an unconditional misconfiguration
and should fail fast at realize time. For v5 I’ll combine both approaches:
1) Realize-time inference + fail-fast
- If a secure-memory address space is wired at realize time, the SMMU
should “do the right thing out of the box” and enable Secure support
automatically.
- If Secure support ends up enabled (either explicitly or via
auto-inference) but secure-memory is missing, smmuv3_realize() will
error out with a clear message.
Importantly, I’ll preserve the explicit user override you mentioned
(-global arm-smmuv3.secure-impl=off).
This is a good summary.
Let's see what other people think about it, and if they are ok with it.
2) Make helpers assume the invariant
With the realize-time invariant in place, the Secure branch in
smmu_get_address_space() will no longer “warn + return NULL”; it will
become an assert (or equivalent hard failure) because the machine
configuration is already validated.
Sounds good.
3) Keep the device-level guard
I will keep smmuv3_validate_sec_sid() as a complementary per-device
guard. This still matters when the user forces secure-impl=off: if a
device declares sec-sid=secure, we can reject it immediately with a
targeted error at device init/hotplug time, which is a different
granularity than the SMMU-wide realize check.
I’ll incorporate these changes in the next revision.
Regards,
Pierrick
