All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Sebastian Ene <sebastianene@google.com>,
	catalin.marinas@arm.com, Sudeep Holla <sudeep.holla@arm.com>,
	joey.gouly@arm.com, maz@kernel.org, oliver.upton@linux.dev,
	snehalreddy@google.com, suzuki.poulose@arm.com,
	vdonnefort@google.com, yuzenghui@huawei.com,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kernel-team@android.com,
	Andrei Homescu <ahomescu@google.com>
Subject: Re: [PATCH v2 4/4] KVM: arm64: Release the ownership of the hyp rx buffer to Trustzone
Date: Thu, 6 Mar 2025 09:40:43 +0000	[thread overview]
Message-ID: <Z8ltm55D1jrv8QtX@bogus> (raw)
In-Reply-To: <20250305193425.GA32246@willie-the-truck>

On Wed, Mar 05, 2025 at 07:34:26PM +0000, Will Deacon wrote:
> On Wed, Mar 05, 2025 at 09:41:04AM +0000, Sudeep Holla wrote:
> > On Wed, Mar 05, 2025 at 12:45:23AM +0000, Will Deacon wrote:
> > > Hmm, the FFA spec is characteristically unclear as to whether or not we
> > > need to release the rx buffer in the case that the flags indicate use of
> > > the rx buffer but the returned partition count is 0.
> > > 
> > > Sudeep -- do you know what we should be doing in that case?
> > > 
> > 
> > We need to call RX_RELEASE here. I went back to the spec to confirm the
> > same again.
> > 
> > v1.2 EAC0 spec Section 7.2.2.4.2 Transfer of buffer ownership
> > (Or just look for the section title in any version of the spec)
> > "
> > 2. Ownership transfer for the RX buffer takes place as follows.
> >     2. For a framework message,
> >        1. Completion of the FFA_PARTITION_INFO_GET ABI transfers the ownership
> >        of the caller’s RX buffer from the Producer to the Consumer.
> > 3. For both types of messages, an invocation of the following FF-A ABIs
> >     transfers the ownership from the Consumer to the Producer.
> >        1. FFA_MSG_WAIT ...
> >        2. FFA_RX_RELEASE.
> > "
> > 
> > Hope that helps, can dig deeper if there are any ambiguities around this.
> 
> Thanks Sudeep, but that also makes it sound like we need the RX_RELEASE
> even if we're not using the RX buffer per the input flags. :/
> 

Good spot, I had forgotten about the input flags that can avoid using the
buffer. I will see if we can improve the spec in that regards.

-- 
Regards,
Sudeep

  reply	other threads:[~2025-03-06  9:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27 18:17 [PATCH v2 0/4] KVM: arm64: Separate the hyp FF-A buffers init from the host Sebastian Ene
2025-02-27 18:17 ` [PATCH v2 1/4] KVM: arm64: Use the static initializer for the vesion lock Sebastian Ene
2025-03-05  0:39   ` Will Deacon
2025-02-27 18:17 ` [PATCH v2 2/4] KVM: arm64: Move the ffa_to_linux definition to the ffa header Sebastian Ene
2025-02-27 20:25   ` Sudeep Holla
2025-02-27 23:12     ` Sebastian Ene
2025-02-28 10:09       ` Marc Zyngier
2025-03-03 23:44         ` Will Deacon
2025-03-04  0:38           ` Sebastian Ene
2025-03-04  9:54           ` Sudeep Holla
2025-03-04  9:57   ` Sudeep Holla
2025-02-27 18:17 ` [PATCH v2 3/4] KVM: arm64: Map the hypervisor FF-A buffers on ffa init Sebastian Ene
2025-03-03 23:43   ` Will Deacon
2025-03-04  0:53     ` Sebastian Ene
2025-03-04  1:56       ` Will Deacon
2025-03-04 17:38         ` Sebastian Ene
2025-03-05  0:38           ` Will Deacon
2025-03-05 18:36             ` Sebastian Ene
2025-03-13 12:04               ` Will Deacon
2025-02-27 18:17 ` [PATCH v2 4/4] KVM: arm64: Release the ownership of the hyp rx buffer to Trustzone Sebastian Ene
2025-03-05  0:45   ` Will Deacon
2025-03-05  9:41     ` Sudeep Holla
2025-03-05 19:34       ` Will Deacon
2025-03-06  9:40         ` Sudeep Holla [this message]
2025-03-13 12:15           ` Will Deacon
2025-03-13 14:00             ` 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=Z8ltm55D1jrv8QtX@bogus \
    --to=sudeep.holla@arm.com \
    --cc=ahomescu@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=sebastianene@google.com \
    --cc=snehalreddy@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=vdonnefort@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.