Hi Rob, On Tue, Mar 30, 2021 at 10:03:12AM -0500, Rob Herring wrote: > On Fri, Mar 26, 2021 at 05:26:52PM +0530, Sumit Garg wrote: > > On Fri, 26 Mar 2021 at 16:25, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > > > On Fri, Mar 26, 2021 at 10:35:23AM +0530, Sumit Garg wrote: > > > > Hi Sudeep, > > > > > > > > Apologies for catching up late on this patch-set. > > > > > > > > On Thu, 25 Mar 2021 at 20:05, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > > > > > > > Since the FF-A v1.0 specification doesn't list the UUID of all the > > > > > partitions in the discovery API, we need to specify the UUID of the > > > > > partitions that need to be accessed by drivers within the kernel. > > > > > > > > > > > > > Wouldn't we be able to implement auto-discovery of ffa partitions? I > > > > think enumeration of ffa partitions on FFA bus should be quite similar > > > > to enumeration of TAs on TEE bus (see [1]). Otherwise we need to put > > > > these redundant DT entries for every ffa partition which IMHO would > > > > bloat up device trees for every platform. > > > > > > > > > > Any suggestions on how to ? Clearly spec doesn't have that provision, I > > > had raised this point in the past. Jens has similar concern and he did > > > ask the same[1]. As I replied to him in that thread[2]. > > > > > > I am open to suggestion on how to auto-discover, currently as I see spec > > > doesn't support it. > > > > > > > Thanks for sharing links to prior discussions and I can see that > > currently spec doesn't support it. But from an implementation > > perspective, I can't find any reason that we can't support > > auto-discover. Have a look at below proposed simple FFA ABI: > > > > FFA_LIST_PARTITIONS > > > > - No input params. > > - Returns an array of secure partition UUIDs to which this non-secure > > virtual/physical FF-A instance is allowed to communicate with. > > > > I think with auto-discovery, one of the major benefits is that if the > > OEM is using a common platform to cater to multiple use-cases which > > rely on different secure partitions then OEM doesn't have to bother > > about shipping separate DTs. > > +1 > > DT should not be the dumping ground for everything forgotten to be made > discoverable. There's not much we can do about h/w, but firmware is > different and can be changed. In other threads (e.g. PCI config space > SMC calls), fixing in firmware is the proposed answer. So let's do that > here. > > Maybe if there are implementations shipping and changing is too late > (yet not too late to use a new binding), then I'd feel differently. But > being in a spec or not alone is not enough reason alone to accept this. > It's obvious the spec did not have wide enough review. The v1.0 specification (released almost one year back) was reviewed by a few Trusted OS vendors amongst other partners. Nobody provided feedback that a FFA_LIST_PARTITIONS like discovery mechanism is a gating factor. Hindsight is a wonderful thing! The ability of discover UUIDs of partitions would indeed be a very useful thing and this will be added to the next version of the specification. I think it is worth providing some background in any case. The usage model envisioned was that a partition would export services that would be identified by a UUID. An FF-A client that wants to use these services would query their presence by specifying this UUID. The FF-A discovery ABI returns a 16-bit ID of the partition that implements the services. This ID is more user-friendly and space efficient than a 16 byte UUID for register and shared memory based IPC between the client and the server. For example, OP-TEE would have a UUID to represent the TEE service. The OP-TEE driver would ask the FF-A driver if there is a partition with a UUID that provides OP-TEE's TEE service. The assumption was that a client must identify the service(s) it wants to access to be able to use FF-A ABIs to talk to the partition that implements them. This was more important than a discovery mechanism where the client says: I don't know what I want but please list all the UUIDs of all partitions in the system. I will then see if I can find anything that I like. In this model, it was not envisioned that the FF-A driver would carry the UUIDs of services that its clients could want to access. The client would know the UUID and the FF-A driver would return the properties of the partition and its ID to enable further communication. We did envision the need for the FF-A driver to know the IDs of all the partitions in the system and their properties e.g. number of vCPUs etc. The FFA_PARTITION_INFO_GET ABI when invoked with a NULL UUID returns this information. It is a bit like "grep *.*". The implementation choice to have an FF-A bus with partitions as devices on it was made after the specification was released. This was not obvious at all at the time of writing the specification. Clearly, in this model the FF-A driver needs to the know the UUIDs. But this does not change the fact that the clients of the FF-A driver still need to know the UUID of the services they are interested in. For v1.0 we are left with no choice but to carry them in the DT. This will be addressed in v1.1. I see this as a case where implementation choices drive the evolution of a specification. I hope you can understand that it was a bit difficult to foresee this usage model for v1.0 when specification and implementation are temporally separated. I also think that this issue is different from the cluster **** the PCIe ECAM SMC discussion is. I do hope this helps clarify the situation to some extent. Please let me know if you need any more info or if I have missed anything. Also, apologies for not getting back sooner as I was on holiday. cheers, Achin
