[PATCH] KVM: arm64: FFA: Release hyp rx buffer

[Sudeep Holla]

On Fri, May 31, 2024 at 06:25:46PM +0100, Vincent Donnefort wrote:
> Hi Sudeep,
> 
> On Thu, May 30, 2024 at 02:17:34PM +0100, Vincent Donnefort wrote:
> > According to the FF-A spec (1.2 BET0 7.2.2.4.2), after a producer has
> > written into a buffer, it is "full" and now owned by the consumer until
> > it is read and "empty". This must be signaled by the consumer with the
> > RX_RELEASE invocation.
> > 
> > It is clear from the spec (7.2.2.4.2), that MEM_RETRIEVE_RESP is
> > transferring the ownership from producer (in our case SPM) to consumer
> > (hypervisor). We must then subsequently invoke RX_RELEASE to transfer
> > back the ownership (i.e. to let SPM mark the buffer as "empty").
> > 
> > It is less clear though what is happening with MEM_FRAG_TX. But this
> > invocation, as a response to MEM_FRAG_RX writes into the same hypervisor
> > RX buffer. Also this is matching the TF-A implementation where the RX
> > buffer is marked "full" during a MEM_FRAG_RX.
> 
> Perhaps a change is needed here in the FF-A spec? Not only it seems strange that
> there are no mention about MEM_FRAG_RX in the buffer ownership paragraph but
> also this seems strange to have to RX_RELEASE: If one invoke MEM_FRAG_RX, that's
> probably because the Rx buffer is ready to be read anyway?
>

Yes, it is kind of implicit.

Under section "Transmission of transaction descriptor in fragments"
subsection "Description", you can see the below statement(just to avoid spec
document version confusion)

"A Receiver must request the Sender to transmit the next fragment through an
invocation of the FFA_MEM_FRAG_RX ABI".

By that it means the receiver(e.g. SPM) has received the current fragment
sent by the sender via FFA_MEM_FRAG_TX(or specific mem API for first fragment)
and it is ready to receive the next when it invokes FFA_MEM_FRAG_RX.

If you think anything can be improved, happy to take it spec authors. I may
be missing to see something obvious.

--
Regards,
Sudeep