On 2026-07-01 15:59 +0300, Ilias Apalodimas wrote: > Hi Harsimran, > > On Sat, 27 Jun 2026 at 17:44, Harsimran Singh Tungal > <[email protected]> wrote: > > > > Add the FF-A runtime infrastructure needed after ExitBootServices() so > > EFI runtime services can continue to use the FF-A transport layer. > > Introduce drivers/firmware/arm-ffa/arm-ffa-runtime.c and > > include/arm_ffa_runtime.h with runtime-resident FF-A helpers for > > direct messaging, SMC invocation, and error translation. Add the > > sandbox runtime SMC wrapper, the ARM_FFA_RT_MODE Kconfig option, and > > the ExitBootServices hook that copies the required FF-A runtime data > > into resident storage before enabling the runtime context. > > > > Tag the runtime code and data with __efi_runtime and > > __efi_runtime_data so they remain available after > > ExitBootServices(). > > > > Reviewed-by: Simon Glass <[email protected]> > > Signed-off-by: Harsimran Singh Tungal <[email protected]> > > Having the FFA driver in drivers/firmware/arm-ffa/ in fine. I am not > so sure about the parts that touch the efi_loader though. I would > prefer having this there. Is there a reason you are defined this in > the ffa driver? > > [...] > > Thanks > /Ilias >
Hi Ilias, Thanks, I think I understand the concern. The reason I placed this in the FF-A driver is that the runtime state being captured is FF-A driver i.e. the endpoint ID and framework version discovered during probe. The ExitBootServices callback only copies that already-discovered FF-A state into runtime-resident storage and enables the runtime context, so I kept the ownership close to the driver that owns the data. The EFI variable TEE code then consumes the runtime FF-A transport through ffa_sync_send_receive_runtime(), without needing to know how the FF-A driver prepares or stores its runtime state. I agree the ExitBootServices hook is EFI-specific. What do you prefer here? Should I move the EFI event registration into efi_loader code? Regards Harsimran Singh Tungal
