From: Sudeep Holla <sudeep.holla@arm.com>
To: Vincent Donnefort <vdonnefort@google.com>
Cc: maz@kernel.org, oliver.upton@linux.dev, sebastianene@google.com,
Sudeep Holla <sudeep.holla@arm.com>,
will@kernel.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, kernel-team@android.com
Subject: Re: [PATCH] KVM: arm64: FFA: Release hyp rx buffer
Date: Tue, 11 Jun 2024 16:47:41 +0100 [thread overview]
Message-ID: <ZmhxnbYCIufu-9XV@bogus> (raw)
In-Reply-To: <ZloIGlEuEiEy3_0v@google.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-06-11 15:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-30 13:17 [PATCH] KVM: arm64: FFA: Release hyp rx buffer Vincent Donnefort
2024-05-31 17:25 ` Vincent Donnefort
2024-06-11 15:47 ` Sudeep Holla [this message]
2024-06-11 13:56 ` Sebastian Ene
2024-06-11 16:17 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZmhxnbYCIufu-9XV@bogus \
--to=sudeep.holla@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=sebastianene@google.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).