[Qualcomm feedback] 7.1.1. IOMMU Registration and Setup

[jyao1]

Reference: https://lists.riscv.org/g/tech-ap-tee-io/topic/103498833#47

The term instance is generally confusing, I think it is referring to the logical instance. Should be reworded in concert with the iommu spec

[sameo]

The term is aligned with the Smmtt spec, where the concept of multiple IOMMU instances per platform/system is introduced.

@ozkoyuncu Any suggestions for a better wording?

[ozkoyuncu]

Here I think the intention is not to associate a "IOMMU instance" (because instance in general imply a physical instantiation of a IOMMU HW IP) with a TSM but rather have a dedicated device context in the IOMMU for the supervisor domain. My suggestion is to use "device context", I think this is the term in IOMMU specification or "translation context". The idea is to associate the full control of the translation for that transaction stream with a particular supervisor domain.

[sameo]

Here I think the intention is not to associate a "IOMMU instance" (because instance in general imply a physical instantiation of a IOMMU HW IP) with a TSM but rather have a dedicated device context in the IOMMU for the supervisor domain.

I don't think giving a dedicated device context to a TSM would be enough as configuration for this context would be exclusively controlled by whoever has the IOMMU programming interface mapped to its address space, which is typically the host SDSM.

An IOMMU instance is not necessarily a physical instantiation of an IOMMU, but it could be a hardware defined separation of a single IOMMU instance a la SRIOV. The fundamental requirement here is that a TSM to which a device is bound to must have exclusive control over the instance programming interface, and that must be MTT enforced.

[sameo]

I propose that we fix that one through #108.

[ozkoyuncu]

Here I think the intention is not to associate a "IOMMU instance" (because instance in general imply a physical instantiation of a IOMMU HW IP) with a TSM but rather have a dedicated device context in the IOMMU for the supervisor domain.

I don't think giving a dedicated device context to a TSM would be enough as configuration for this context would be exclusively controlled by whoever has the IOMMU programming interface mapped to its address space, which is typically the host SDSM.

An IOMMU instance is not necessarily a physical instantiation of an IOMMU, but it could be a hardware defined separation of a single IOMMU instance a la SRIOV. The fundamental requirement here is that a TSM to which a device is bound to must have exclusive control over the instance programming interface, and that must be MTT enforced.

Agreed, in that case articulating "exclusive control" of the programming interface may suffice. it is important to list the requirements - and to clarify the term "instance" as it correlates to such requirements and maybe refer to examples of how they can be achieved.
so our original question is answered, it is a matter of further clarification for wider audience

[sameo]

@ozkoyuncu We just merged #111 and I think this addresses this issue. Let me know if that's the case and we will close that issue.

[ozkoyuncu]

@sameo I have read the clarification and it lgtm. thanks

[sameo]

Fixed with #111