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

[Sebastian Ene <sebastianene@google.com>]

On Mon, Jun 08, 2026 at 03:40:30PM +0100, Will Deacon wrote:
> Hey Seb,
> 
> On Mon, Jun 08, 2026 at 02:22:22PM +0000, Sebastian Ene wrote:
> > On Fri, May 29, 2026 at 04:32:24PM +0100, Will Deacon wrote:
> > > 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).
> 
> For unused parameter registers that are SBZ, I think you could just add
> a helper, e.g.:
> 
> 	ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int reg);
> 
> which takes the index of the first unused register and then checks that
> all the registers from there to the last unused parameter register are
> zero. You can then just call that directly before you start parsing the
> SBZ/MBZ fields on the used parameter registers and there's no need for
> the table-based indirection in [1].

I see, will do that, thanks.

Sebastian

> 
> Will
> 
> [1] https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/