Hi,
Thanks for raising this topic.
The 20000 cycles data come from the debug mode, which has extra costs spent on debug handling. The release mode can reduce about 50% to make it close to 10000 cycles.
Optimization is one of the project’s main scope , it is still ongoing, and now we mainly focus on size optimization under the SFN model. For performance optimization under isolation level 2 and 3, as the cross-privilege
calls can't be avoided, we planned to do it in the subsequent quarters.
PS: SFN model works under isolation level 1 only, this could save the efforts for context switching. For high level isolations, SFN partitions are working under a compatible model that act as IPC, and this model does
not affect the partition writers – it is covered by SPM.
Due to there are a couple of working threads ongoing, it is warmly welcome optimization commits from the community, for example:
- Logic optimization to save execution cycles.
- Remove unused code/data.
- Make unnecessary logic configurable (Do not remove them directly).
Please do submit these changes if you already have some. For big changes you can propose the idea here and we can discuss. Looking forward to seeing the follow-up.
BR
/Ken
From: Bøe, Sebastian via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Friday, February 18, 2022 11:51 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] FF PSA API overhead
Hi,
the performance improvement presentation[0] reports a FF PSA API overhead
of 20 000 CPU cycles for the psa_call. Which is 300 us for a 64MHz CPU.
This is quite a lot of instructions and I am concerned about whether
real world embedded application's will have time to call these secure services.
I'm interested in isolation level 2.
I understand that it is not possible to have isolation level 2 with library mode. But what about SFN
mode, could that eventually support isolation level 2?
If not, what is the current status of optimizing the service call overhead for IPC.
Is it considered to be as optimized as it can be or is there still hope for optimizing further?