Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@kernel.org>
To: Jamie Nguyen <jamien@nvidia.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Sudeep Holla <sudeep.holla@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
Date: Fri, 15 May 2026 10:23:40 +0100	[thread overview]
Message-ID: <20260515-zippy-notorious-caiman-ea4ec6@sudeepholla> (raw)
In-Reply-To: <5AF8DFBF-18EC-4C8A-84A0-F27298DB9BD0@nvidia.com>

On Thu, May 14, 2026 at 05:37:38PM +0000, Jamie Nguyen wrote:
> 
> 
> > On May 14, 2026, at 2:16 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> > 
> > On Wed, May 13, 2026 at 07:48:05PM +0000, Jamie Nguyen wrote:
> >> 
> >> 
> >>> On May 13, 2026, at 10:15 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> >>> 
> >>> On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
> >>>> __ffa_partition_info_get_regs() walks the response with a hardcoded
> >>>> 24-byte stride (regs += 3) even though the SPMC tells us the actual
> >>>> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
> >>>> read into buf_sz and then thrown away.
> >>>> 
> >>>> That works while every SPMC returns the FF-A v1.1 layout, but it falls
> >>>> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
> >>>> strides over half a descriptor at a time and ends up parsing every
> >>>> other entry from a slice of two adjacent ones.
> >>>> 
> >>>> The FF-A spec (v1.2, section 18.5) says that the producer should
> >>>> report the descriptor size, and the consumer is supposed to stride by
> >>>> that size and ignore any trailing fields it doesn't understand. The
> >>>> non-REGS path (__ffa_partition_info_get) does this already, and the
> >>>> REGS path should match.
> >>>> 
> >>>> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
> >>>> reports something we can't safely walk.
> >>>> 
> >>> 
> >>> Can you check if the issue is addressed in -next by:
> >>> Commit 3974ea193840 ("firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies")
> >> 
> >> Thanks for the pointer.  I tested 3974ea193840 on the same hardware
> >> that reproduces the bug, but the descriptor-stride issue is still
> >> present.
> >> 
> >> The relevant loop at the end of __ffa_partition_info_get_regs()
> >> still has:
> >> 
> >> buf_sz = PARTITION_INFO_SZ(partition_info.a2);
> >> if (buf_sz > sizeof(*buffer))
> >> buf_sz = sizeof(*buffer);
> >> ...
> >> for (idx = 0; idx < nr_desc; idx++, buf++) {
> >> ...
> >> regs += 3;  /* bug is here */
> >> }
> >> 
> >> With 48-byte descriptors the SPMC returns nr_desc = 2 per call,
> > 
> > Well why is the firmware sending 48byte entry when 24byte is expected.
> 
> We're starting to test with a v1.3 SPMC implementation.  UEFI brings
> up its FF-A driver first and negotiates v1.3, which the SPMC then must
> keep for the lifetime of the primary VM per DEN0077A v1.2 REL0 section
> 13.2.2 [0]:
> 
>     "Once an FF-A version has been negotiated between a caller and a
>      callee, the version may not be changed for the lifetime of the
>      calling component.”
> 

I need to check the v1.3-alpha specs to understand/recall the version
negotiations but until v1.2 and the current driver which is v1.2 we don't
have any idea about all these new changes. But since v1.2 already has size
of descriptor, we can and must handle that independently of this new
version (re-)negotiation.

-- 
Regards,
Sudeep


  reply	other threads:[~2026-05-15  9:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13  3:28 [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS Jamie Nguyen
2026-05-13 17:15 ` Sudeep Holla
2026-05-13 19:48   ` Jamie Nguyen
2026-05-14  9:16     ` Sudeep Holla
2026-05-14 17:37       ` Jamie Nguyen
2026-05-15  9:23         ` Sudeep Holla [this message]
2026-05-14  9:31 ` Sudeep Holla
2026-05-14 17:37   ` Jamie Nguyen
2026-05-15  9:40     ` 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=20260515-zippy-notorious-caiman-ea4ec6@sudeepholla \
    --to=sudeep.holla@kernel.org \
    --cc=jamien@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.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