Hi all, I am sending this note to get feedback from platform maintainers on an EL3 SPMC change in my current series (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/50778/).
The patch updates spmc_ffa_mem_retrieve_req() to take a snapshot of the caller's FFA_MEM_RETRIEVE_REQ descriptor into the EL3 SPMC shmem datastore before validation and response handling. The intent is to avoid repeatedly reading mutable fields from the caller-owned TX buffer while the request is being processed. In other words, once the request enters EL3 SPMC, we operate on a stable local copy rather than on memory that remains under the caller's control.
The EL3 SPMC datastore is already used to cache shared memory transaction descriptors. With this change, it is also used to hold a temporary copy of the retrieve request. That means datastore sizing becomes more important, since a valid larger retrieve request may now fail if the backing datastore is too small.
The datastore sizes are defined in platform_def.h (https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+... the fvp platform) and while looking through the existing platform definitions, I noticed that datastore sizes vary quite a lot. For example, some platforms provide a relatively large backing store, while others define much smaller regions. In particular, rdn2 currently defines only a 1024-byte datastore. My concern is that for such platforms, larger memory-share / retrieve flows could fail simply because the datastore is too small to hold the request snapshot.
Before I proceed further, I wanted to ask platform maintainers: 1. Is there any platform-specific reason for these reduced datastore sizes? 2. If not, would maintainers be happy for these datastore sizes to be increased so they can accommodate larger valid transactions?
In short, I want to confirm whether the smaller datastore definitions are deliberate platform constraints, or whether they should be treated as undersized defaults that now need revisiting.
Feedback from maintainers would be very helpful before I post the next revision.
Kind Regards, Daniel Boulby