Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: perlarsen@google.com, Oliver Upton <oliver.upton@linux.dev>,
	Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, ahomescu@google.com,
	armellel@google.com, arve@android.com, ayrton@google.com,
	qperret@google.com, sebastianene@google.com, qwandor@google.com
Subject: Re: [PATCH v7 4/5] KVM: arm64: Bump the supported version of FF-A to 1.2
Date: Tue, 5 Aug 2025 15:49:06 +0100	[thread overview]
Message-ID: <aJIZ4v0X74zox1xZ@willie-the-truck> (raw)
In-Reply-To: <86zfck7pys.wl-maz@kernel.org>

Hey Marc,

(we discussed this very briefly offline but I wanted to reply for the
benefit of everybody else and also because I don't recall quite where we
ended up)

On Thu, Jul 31, 2025 at 08:56:59AM +0100, Marc Zyngier wrote:
> On Fri, 18 Jul 2025 14:45:17 +0100,
> Will Deacon <will@kernel.org> wrote:
> > On Tue, Jul 01, 2025 at 10:06:37PM +0000, Per Larsen via B4 Relay wrote:
> > > From: Per Larsen <perlarsen@google.com>
> > > @@ -734,7 +741,10 @@ static int hyp_ffa_post_init(void)
> > >  	if (res.a0 != FFA_SUCCESS)
> > >  		return -EOPNOTSUPP;
> > >  
> > > -	switch (res.a2) {
> > > +	if ((res.a2 & GENMASK(15, 2)) != 0 || res.a3 != 0)
> > > +		return -EINVAL;
> > 
> > Why are you checking bits a2[15:2] and a3? The spec says they MBZ,
> > so we shouldn't care about enforcing that. In fact, adding the check
> > probably means we'll fail if those bits get allocated in future.
> 
> I have the exact opposite approach. If we don't check that they are 0
> for v1.2 and previous versions, we won't be able to tell what they
> mean when they are finally allocated to mean something in version
> 1.337.
> 
> Until we support such version, MBZ should be enforced, because we
> otherwise don't understand what the "client" is trying to say. And we
> don't understand, we're guaranteed to do the wrong thing.

We've lost a bunch of context in the diff here, but there are two
important things to keep in mind at this point:

  1. We've negotiated a known version of FF-A, so it won't be v1.337 and
     we _should_ be able rely on the spec authors not breaking stuff
     retrospectively (famous last words...)

  2. The response we're parsing here is something that has come back
     from TZ after we (the hypervisor) have called FFA_FEATURES. If
     those MBZ bits are non-zero, I think should just ignore them.

Cheers,

Will


  reply	other threads:[~2025-08-05 16:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-01 22:06 [PATCH v7 0/5] KVM: arm64: Support FF-A 1.2 and SEND_DIRECT2 ABI Per Larsen via B4 Relay
2025-07-01 22:06 ` [PATCH v7 1/5] KVM: arm64: Correct return value on host version downgrade attempt Per Larsen via B4 Relay
2025-07-01 22:06 ` [PATCH v7 2/5] KVM: arm64: Use SMCCC 1.2 for FF-A initialization and in host handler Per Larsen via B4 Relay
2025-07-03 12:38   ` Marc Zyngier
2025-07-08  0:06     ` Per Larsen
2025-07-18 13:37       ` Will Deacon
2025-07-19  5:54         ` Per Larsen
2025-07-21 11:01           ` Arve Hjønnevåg
2025-07-22  0:20             ` Per Larsen
2025-07-22 15:55               ` Will Deacon
2025-07-01 22:06 ` [PATCH v7 3/5] KVM: arm64: Mark FFA_NOTIFICATION_* calls as unsupported Per Larsen via B4 Relay
2025-07-01 22:06 ` [PATCH v7 4/5] KVM: arm64: Bump the supported version of FF-A to 1.2 Per Larsen via B4 Relay
2025-07-18 13:45   ` Will Deacon
2025-07-31  7:56     ` Marc Zyngier
2025-08-05 14:49       ` Will Deacon [this message]
2025-07-01 22:06 ` [PATCH v7 5/5] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ2 in host handler Per Larsen via B4 Relay
2025-07-18 13:53   ` Will Deacon
2025-07-21 11:13     ` Arve Hjønnevåg
2025-07-21 22:43     ` Per Larsen
2025-07-22 15:03       ` Will Deacon

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=aJIZ4v0X74zox1xZ@willie-the-truck \
    --to=will@kernel.org \
    --cc=ahomescu@google.com \
    --cc=armellel@google.com \
    --cc=arve@android.com \
    --cc=ayrton@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.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=perlarsen@google.com \
    --cc=qperret@google.com \
    --cc=qwandor@google.com \
    --cc=sebastianene@google.com \
    --cc=sudeep.holla@arm.com \
    --cc=suzuki.poulose@arm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox