Re: [PATCH] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone

[Sebastian Ene <sebastianene@google.com>]

On Fri, May 29, 2026 at 04:32:24PM +0100, Will Deacon wrote:
> On Fri, May 08, 2026 at 01:04:27PM +0000, Sebastian Ene wrote:
> > While at it I discovered that none of the FF-A calls in the proxy
> > currently check for these SBZ registers. Would you be ok with a diff that
> > fixes this before the patch with the notifications ?

Hi Will,

> 
> I'd probably structure it as a separate patch per call, tbh. That way,
> the commit message can talk about the specific fields that are reserved
> for a given call. See below.
> 
> > Refactor the handling logic in pKVM FF-A proxy to support checking for
> > SBZ/MBZ values. While at it, drop the do_ffa_mem_xfer macro and replace
> > it with two functions that make it clear that we re-write the
> > function-id with a 64-bit variant, to keep the same behavior as before.
> > Keep each handler in an array of structures together with a mask that
> > corresponds to the SBZ registers the spec expects.
> 
> Although I agree that we should be enforcing SBZ/MBZ paramaters (because
> we have no idea what they might do in future versions of the spec), I
> also think that doing this at the register level is too coarse.
> 
> For example, the VM ID parameter to FFA_NOTIFICATION_BITMAP_CREATE has bits
> 31:16 as MBZ. So I think we probably need to do the checking on a
> per-function basis, like Per is doing in his series:
> 
> https://lore.kernel.org/r/20260501-host-direct-messages-v6-0-3f4af727ed85@google.com
> 

For the newly added calls like FFA_NOTIFICATION_* we can do that in a
separate functions, but what about the other existing calls that have
MBZ registers ? that was the reason for the inline proposal in :
https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/
(to avoid duplicate checks).

> Will

Thanks,
Sebastian