On Tue, 10 Aug 2021 at 11:51, Olivier Deprez Olivier.Deprez@arm.com wrote:
Hi Andrew,
I have submitted the change as you have passed it through the ML as a base for the discussion. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/11002
Thanks, it sounds like you have better ideas for addressing this more neatly which is great!
The issue is acknowledged, we had a brief discussion internally as to how best to refactor if need be.
It looks to us the main problem is that SPM-MM (pre-dating FF-A) has aged a bit and mixes standard and impdef func ids.
e.g. MM is an Arm standard and only defines two func ids (0x84000040, 0x84000041) so it may just be a matter of updating SPM_MM_FID_MAX_VALUE to 0x41 such that MM related services go through.
The other ids 0xX4000060, 61, 64, 65 are purely impdef for the SPM-MM to/from SP communication. Thus we may define SP_MM_FID_MIN_VALUE/SP_MM_FID_MAX_VALUE and a corresponding is_sp_mm_fid macro. This would avoid the clash with TRNG IDs (0xX4000050, 51, 52, 53).
What do you reckon?
Yep, that makes sense to me.
Btw out of curiosity how did you discover this? Do you have a setup enabling both SPM_MM and TRNG_SUPPORT option? Or maybe this is because of Trusty SPD reuse of spm_mm_smc_handler?
For pKVM, we rely on FF-A memory sharing with secure world and TRNG. This setup was based on the Trusty fork [1], rather than enabling SPM_MM, and when I then tried to enable TRNG_SUPPORT it wasn't getting through because of this issue.
[1] -- https://android.googlesource.com/trusty/external/trusted-firmware-a/+/refs/h...