[PATCH 12/12] efi_loader: align FF-A cache maintenance with runtime path

Simon Glass sjg at chromium.org
Tue Apr 28 20:14:47 CEST 2026


Hi Harsimran,

On 2026-04-24T17:31:50, Harsimran Singh Tungal
<harsimransingh.tungal at arm.com> wrote:
> efi_loader: align FF-A cache maintenance with runtime path
>
> Match boot-time FF-A cache handling to runtime behavior
>
> The boot-time FF-A MM communication path used invalidate_dcache_all()
> after copying the message into the shared buffer. This differs from the
> runtime path, which performs range-based maintenance to avoid global cache
> operations.
>
> Update ffa_mm_communicate() to use the same pattern as the runtime helper:
> clean the shared buffer range before the SMC and invalidate the same range
> after the response. This keeps boot-time and runtime behavior consistent
> and avoids whole-cache invalidation.
>
> Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi at arm.com>
> Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal at arm.com>
>
> lib/efi_loader/efi_variable_tee.c | 33 ++++++++++++++++++++++++++-------
>  1 file changed, 26 insertions(+), 7 deletions(-)

> diff --git a/lib/efi_loader/efi_variable_tee.c b/lib/efi_loader/efi_variable_tee.c
> @@ -389,19 +389,38 @@ static efi_status_t ffa_mm_communicate(void *comm_buf, ulong comm_buf_size)
>       memcpy(virt_shared_buf, comm_buf, tx_data_size);
>
>       /*
> -      * The secure world might have cache disabled for
> -      * the device region used for shared buffer (which is the case for Optee).
> -      * In this case, the secure world reads the data from DRAM.
> -      * Let's flush the cache so the DRAM is updated with the latest data.
> +      * Shared buffer cache maintenance for FF-A / OP-TEE communication:
> +      *
> +      * NS -> S (request path):
> +      *
> +      * The non-secure side populates the shared buffer. If the buffer is cached
> +      * in NS, the updated bytes may reside in dirty D-cache lines and not yet be
> +      * visible in DDR. Since the secure world typically reads the shared buffer
> +      * directly from DDR (e.g. with caches disabled / non-coherent mapping), we
> +      * must clean the corresponding cache lines to the Point of Coherency (PoC)
> +      * before entering secure world.
> +      *
> +      * S -> NS (response path):
> +      *
> +      * The secure world may update the same shared buffer in DDR. After returning
> +      * to non-secure, any cached copies of that region in NS may be stale. We
> +      * therefore invalidate the shared buffer range after the FF-A call to drop
> +      * those lines and force subsequent reads to fetch the latest data from DDR.
>        */

This 20-line comment is now duplicated verbatim with the one in
ffa_mm_communicate_runtime() introduced earlier in the series. Please
factor the clean-before / invalidate-after sequence into a small
helper (e.g. ffa_mm_buf_pre_call() / ffa_mm_buf_post_call()) so the
commentary lives in one place and the two paths cannot drift. The
runtime helper would add the extra 'no whole-cache invalidation after
ExitBootServices()' note at the call site.

> diff --git a/lib/efi_loader/efi_variable_tee.c b/lib/efi_loader/efi_variable_tee.c
> @@ -389,19 +389,38 @@ static efi_status_t ffa_mm_communicate(void *comm_buf, ulong comm_buf_size)
> -#ifdef CONFIG_ARM64
> -     invalidate_dcache_all();
> -#endif
> +     if (IS_ENABLED(CONFIG_ARM64))
> +             flush_dcache_range((unsigned long)virt_shared_buf,
> +                                (unsigned long)virt_shared_buf +
> +                                CONFIG_FFA_SHARED_MM_BUF_SIZE);

Just to check - flush_dcache_range() and invalidate_dcache_range() on
arm64 require start and end to be cache-line aligned, otherwise the
arch code warns and falls back to clean+invalidate of the partial
lines. CONFIG_FFA_SHARED_MM_BUF_ADDR and _SIZE need to be at least
CONFIG_SYS_CACHELINE_SIZE aligned - is that documented or enforced
anywhere? You could use BUILD_BUG_ON() near the call, perhaps?

> diff --git a/lib/efi_loader/efi_variable_tee.c b/lib/efi_loader/efi_variable_tee.c
> @@ -389,19 +389,38 @@ static efi_status_t ffa_mm_communicate(void *comm_buf, ulong comm_buf_size)

The commit message body opens with 'Match boot-time FF-A cache
handling to runtime behavior', which restates the subject. Please drop
that line and start directly with the problem paragraph per the U-Boot
convention of leading with motivation.

Regards,
Simon


More information about the U-Boot mailing list