From: Jamie Nguyen <jamien@nvidia.com>
To: Sudeep Holla <sudeep.holla@kernel.org>
Cc: Jamie Nguyen <jamien@nvidia.com>, <linux-acpi@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Hanjun Guo <guohanjun@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Dat Mach <dmach@nvidia.com>
Subject: Re: [PATCH v2 3/3] firmware: arm_ffa: Share FF-A version negotiation
Date: Thu, 12 Nov 2026 08:30:47 -0800 [thread overview]
Message-ID: <20261112163047.575186-1-jamien@nvidia.com> (raw)
In-Reply-To: <20261112-acpi_ffh_ffa-v2-3-575a9dbed22b@kernel.org>
On Thu, Nov 12, 2026 at 11:14:08AM +0000, Sudeep Holla wrote:
[...]
> + guard(mutex)(&ffa_version_lock);
> + if (!ffa_version) {
> + invoke(&args, &res);
Can this scenario happen?
1) pKVM is enabled but not yet initialised, and offset-2 AML runs
(e.g. during the initial ACPI scan), so ffh.c gets here first and
negotiates directly with EL3.
2) The result is cached.
3) Once pKVM is up, ffa_version_check() gets the cached version and
never sends FFA_VERSION through the proxy.
If so, then I think kvm_host_ffa_handler() would reject the transport's
calls, since has_version_negotiated is never set.
Should we decline here instead, without caching, while
is_protected_kvm_enabled() && !is_pkvm_initialized(), like ffa_probe()
already does?
prev parent reply other threads:[~2026-11-12 16:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 11:14 [PATCH v2 0/3] ACPI: Arm FFH: Add support for OpRegion Offset 2 (FF-A DIRECT_REQ2) Sudeep Holla
2026-11-12 11:14 ` [PATCH v2 1/3] firmware: arm_ffa: Share FF-A register field definitions Sudeep Holla
2026-11-12 11:14 ` [PATCH v2 2/3] ACPI: FFH: Support FF-A direct request 2 calls Sudeep Holla
2026-11-12 11:14 ` [PATCH v2 3/3] firmware: arm_ffa: Share FF-A version negotiation Sudeep Holla
2026-11-12 16:30 ` Jamie Nguyen [this message]
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=20261112163047.575186-1-jamien@nvidia.com \
--to=jamien@nvidia.com \
--cc=catalin.marinas@arm.com \
--cc=dmach@nvidia.com \
--cc=guohanjun@huawei.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=sudeep.holla@kernel.org \
--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