Hi Jens, > On 11 Feb 2026, at 14:34, Jens Wiklander <[email protected]> wrote: > > Hi Bertrand, > > On Wed, Feb 11, 2026 at 12:27 PM Bertrand Marquis > <[email protected]> wrote: >> >> Hi Jens, >> >>> On 11 Feb 2026, at 09:17, Jens Wiklander <[email protected]> wrote: >>> >>> Hi Bertrand, >>> >>> On Tue, Feb 3, 2026 at 6:38 PM Bertrand Marquis >>> <[email protected]> wrote: >>>> >>>> FFA_FEATURES currently accepts non-zero input properties (w2-w7) from >>>> guests and advertises several ABIs unconditionally, even when firmware >>>> support is missing or when the ABI is physical-instance-only. This can >>>> mislead guests about what Xen can actually provide and violates FF-A >>>> calling conventions. Some SPMCs (Hafnium v2.14 or earlier) also fail to >>>> report FFA_RX_ACQUIRE despite supporting it. >>>> >>>> Update FFA_FEATURES validation to match spec and firmware support: >>>> - reject non-zero w2-w7 input properties with INVALID_PARAMETERS >>>> - reject 64-bit calling conventions from 32-bit guests with NOT_SUPPORTED >>>> - return NOT_SUPPORTED for physical-instance-only ABIs >>>> (FFA_NOTIFICATION_BITMAP_{CREATE,DESTROY}, FFA_RX_ACQUIRE) >>>> - advertise FFA_INTERRUPT as supported >>>> - gate message ABIs on firmware support: >>>> - FFA_MSG_SEND_DIRECT_REQ_{32,64} >>>> - FFA_MSG_SEND_DIRECT_REQ2 (also requires FF-A 1.2 negotiation) >>>> - FFA_MSG_SEND2 (or VM-to-VM enabled) >>>> - report MEM_SHARE_{32,64} only when FFA_MEM_SHARE_64 is supported >>>> - stop advertising FFA_MSG_YIELD (not implemented) >>>> >>>> Update firmware probing: drop FFA_MEM_SHARE_32 checks (deprecated) and >>>> add FFA_RX_ACQUIRE to the probed set. If FFA_MSG_SEND2 is reported but >>>> FFA_RX_ACQUIRE is not, assume RX_ACQUIRE support and warn to work >>>> around the Hafnium bug. >>>> >>>> Functional impact: guests now see ABI support that reflects firmware >>>> capabilities and Xen implementation status. When SEND2 is present but >>>> RX_ACQUIRE is not reported, Xen assumes RX_ACQUIRE support. >>>> >>>> Signed-off-by: Bertrand Marquis <[email protected]> >>>> --- >>>> xen/arch/arm/tee/ffa.c | 62 +++++++++++++++++++++++++++++++++++++----- >>>> 1 file changed, 55 insertions(+), 7 deletions(-) >>>> >>>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c >>>> index 6de2b9f8ac8e..e9e020bb0cb3 100644 >>>> --- a/xen/arch/arm/tee/ffa.c >>>> +++ b/xen/arch/arm/tee/ffa.c >>>> @@ -91,10 +91,10 @@ static const struct ffa_fw_abi ffa_fw_abi_needed[] = { >>>> FW_ABI(FFA_PARTITION_INFO_GET), >>>> FW_ABI(FFA_NOTIFICATION_INFO_GET_64), >>>> FW_ABI(FFA_NOTIFICATION_GET), >>>> + FW_ABI(FFA_RX_ACQUIRE), >>>> FW_ABI(FFA_RX_RELEASE), >>>> FW_ABI(FFA_RXTX_MAP_64), >>>> FW_ABI(FFA_RXTX_UNMAP), >>>> - FW_ABI(FFA_MEM_SHARE_32), >>>> FW_ABI(FFA_MEM_SHARE_64), >>>> FW_ABI(FFA_MEM_RECLAIM), >>>> FW_ABI(FFA_MSG_SEND_DIRECT_REQ_32), >>>> @@ -240,19 +240,39 @@ static void handle_features(struct cpu_user_regs >>>> *regs) >>>> struct ffa_ctx *ctx = d->arch.tee; >>>> unsigned int n; >>>> >>>> + /* >>>> + * Xen does not accept any non-zero FFA_FEATURES input properties from >>>> + * VMs. The spec only defines w2 input properties for >>>> FFA_MEM_RETRIEVE_REQ >>>> + * (NS-bit negotiation for SP/SPMC) and FFA_RXTX_MAP (buffer size and >>>> + * alignment), so w2 must be MBZ for our callers. >>>> + */ >>> >>> The spec (version 1.2) lists them as SBZ, except for w2, which is MBZ, >>> for Feature IDs. >> >> Very true, this should only check w2 which is anyway defined as MBZ when >> not used. >> w3-w7 were MBZ in previous versions of FF-A but are in fact SBZ in 1.2 so >> we should ignore them >> >>> However, if we're to return an error, invalid parameters is a better choice. >> >> In fact the spec is actually saying the following: >> If the FF-A interface or feature that was queried is not implemented or >> invalid, >> the callee completes this call with an invocation of the FFA_ERROR interface >> with the NOT_SUPPORTED error code. >> >> So there is no case for INVALID_PARAMETER. > > You're right. > >> >> So in fact i should: >> - return NOT_SUPPORTED if w2 is not 0 >> - ignore w3-w7 >> >> Can you confirm that you have the same reading of the spec than me ? > > The 1.2 spec only says this w2 is MBZ for Feature IDs, and that w2 is > SBZ for FFA_RXTX_MAP. The 1.3 spec says the same, except that in Table > 13.14: Feature IDs and properties table, it lists w2 as SBZ. > > Note that FFA_MEM_RETRIEVE_REQ has bits defined in w2, and the unknown > bits are SBZ. > > Based on that, I'm inclined to keep it simple and ignore w2-w7.
That would make sense, I agree. I will check why FF-A ACS was failing when i did not have this and if it still the case and come back to you if ignoring is not acceptable (with a reason). Cheers Bertrand
