On Tue, Jun 03, 2025 at 05:04:33PM +0100, Peter Maydell wrote:

On Tue, 3 Jun 2025 at 16:53, Lorenzo Pieralisi [off-list ref] wrote:

quoted

Specifically, for IRS/ITS frames then - what the current schema does is
correct, namely, it does _not_ spell out whether the IRS/ITS config
frame is NS/S/Realm/Root interrupt domain, that's information that the
client implicitly assumes.

Are we OK with this approach ? This would leave open the possibility
of having a DT per security-state.

If in the DT schema I define eg reg -> "IRS NS config frame" by
construction the binding can't be used for anything else.

Please let me know if we are in agreement on this matter.

This would break the QEMU virt board -> EL3 guest firmware ->
EL1 Linux flow. We need a binding which lets us optionally
specify "oh by the way here is where the other non-NS frames are".

Do we "need" a binding ? Or, it is a nice-have to help configure
QEmu (and other SW components, eg bootwrapper/TF-A, etc that decided
to re-use DT for their own consumption) ?

And even so, why can't we have a DT per security state as-per Rob's
reply ?

Given that only the "status" property is tagged with secure- today,
may I ask please how does this work ?

What's "EL3 guest firmware" ? Does it use the secure-status property to
detect that the respective device is secure/non-secure ?

And why does it have to be the same dtb we are passing to the OS client ?

I don't have a strong view on the specific syntax.

I do because I don't want to revisit this later ;-)

Thanks,
Lorenzo