[PATCH v2 3/4] KVM: arm64: Map the hypervisor FF-A buffers on ffa init

Will Deacon will at kernel.org
Mon Mar 3 17:56:35 PST 2025


On Tue, Mar 04, 2025 at 12:53:25AM +0000, Sebastian Ene wrote:
> On Mon, Mar 03, 2025 at 11:43:03PM +0000, Will Deacon wrote:
> > On Thu, Feb 27, 2025 at 06:17:48PM +0000, Sebastian Ene wrote:
> > > Map the hypervisor's buffers irrespective to the host and return
> > > a linux error code from the FF-A error code on failure. Remove
> > > the unmap ff-a buffers calls from the hypervisor as it will
> > > never be called.
> > > Prevent the host from using FF-A directly with Trustzone
> > > if the hypervisor could not map its own buffers.
> > > 
> > > Signed-off-by: Sebastian Ene <sebastianene at google.com>
> > > ---
> > >  arch/arm64/kvm/hyp/nvhe/ffa.c | 46 +++++++++++++----------------------
> > >  1 file changed, 17 insertions(+), 29 deletions(-)
> > 
> > [...]
> > 
> > > @@ -861,6 +842,7 @@ int hyp_ffa_init(void *pages)
> > >  {
> > >  	struct arm_smccc_res res;
> > >  	void *tx, *rx;
> > > +	int ret;
> > >  
> > >  	if (kvm_host_psci_config.smccc_version < ARM_SMCCC_VERSION_1_2)
> > >  		return 0;
> > > @@ -911,5 +893,11 @@ int hyp_ffa_init(void *pages)
> > >  		.lock	= __HYP_SPIN_LOCK_UNLOCKED,
> > >  	};
> > >  
> > > +	/* Map our hypervisor buffers into the SPMD */
> > > +	ret = ffa_map_hyp_buffers();
> > > +	if (ret)
> > > +		return ret;
> > 
> > Doesn't calling RXTX_MAP here undo the fix from c9c012625e12 ("KVM:
> > arm64: Trap FFA_VERSION host call in pKVM") where we want to allow for
> > the host to negotiate the version lazily?
> 
> We still have the same behaviour where we don't allow memory
> sharing to happen until the version is negotiated but this
> separates the hypervisor buffer mapping part from the host.

Sadly, the spec doesn't restrict this to the memory sharing calls:

  | [...] negotiation of the version must happen before an invocation of
  | any other FF-A ABI

We're also probing the minimum rxtx size in hyp_ffa_post_init() so doing
this here is doubly wrong.

So I think we should probably just drop this patch.

Will



More information about the linux-arm-kernel mailing list