Regarding the Non-secure Client Management proposal:
https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/
I notice that the veneers for the proposed APIs are in s_veneers.o. Does this mean that the proposal has been adopted and implemented? Is it functional in the current feature-ipc branch?
I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: Is it expected that each context switch in the NS world will be signaled by calls to each of these APIs indicating the "entering" context and "leaving" context respectively? If so, then why not collapse these two APIs into one called TZ_SwitchContext__S() and pass both the "entering" and "leaving" TZ_MemoryId_t's as arguments?
Or is TZ_StoreContext_S() only to be called when a NS context will never call into the SPM again? If that is the case, why isn't TZ_FreeModuleContext_S() sufficient?
Regarding the "Concurrent secure service requests" discussion, what does "a non-secure client is blocked on an asynchronous secure service completion"? Would this be achieved by a special return status from psa_call() indicating that the current service request is in process and will complete later on? The psa_call() calling thread would then block on a semaphore that would be released by a dedicated NS IRQ interrupt? Is any of this functionality in place yet?
Alan