From: Sebastian Ene <sebastianene@google.com>
To: Will Deacon <will@kernel.org>
Cc: perlarsen@google.com, Marc Zyngier <maz@kernel.org>,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Yeoreum Yun <yeoreum.yun@arm.com>,
Ben Horgan <ben.horgan@arm.com>, Oliver Upton <oupton@kernel.org>,
Armelle Laine <armellel@google.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in host handler
Date: Fri, 9 Jan 2026 11:18:33 +0000 [thread overview]
Message-ID: <aWDkCQ7m1-w8e-Py@google.com> (raw)
In-Reply-To: <aV_MnW8cg7IsWPuD@willie-the-truck>
On Thu, Jan 08, 2026 at 03:26:21PM +0000, Will Deacon wrote:
Hi Will,
> On Wed, Nov 19, 2025 at 02:07:53AM +0000, Per Larsen via B4 Relay wrote:
> > From: Sebastian Ene <sebastianene@google.com>
> >
> > Allow direct messages to be forwarded from the host. The host should
> > not be sending framework messages so they are filtered out.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > Signed-off-by: Per Larsen <perlarsen@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 22 ++++++++++++++++++++++
> > include/linux/arm_ffa.h | 3 +++
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 58b7d0c477d7fce235fc70d089d175c7879861b5..a38a3ab497e5eac11777109684a33f02d88d09a1 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -862,6 +862,23 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
> > hyp_spin_unlock(&host_buffers.lock);
> > }
> >
> > +static void do_ffa_direct_msg(struct arm_smccc_1_2_regs *res,
> > + struct kvm_cpu_context *ctxt,
> > + u64 vm_handle)
> > +{
> > + DECLARE_REG(u32, flags, ctxt, 2);
> > +
> > + struct arm_smccc_1_2_regs *args = (void *)&ctxt->regs.regs[0];
> > +
> > + /* filter out framework messages */
> > + if (FIELD_GET(FFA_MSG_FLAGS_MSG_TYPE, flags)) {
>
> Wouldn't we be better off just checking that flags is 0? The rest of it
> is SBZ or MBZ in the current spec.
Yes, we can simplify it in this way.
>
> > + ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
> > +
> > + arm_smccc_1_2_smc(args, res);
> > +}
> > +
> > bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > {
> > struct arm_smccc_1_2_regs res;
> > @@ -920,6 +937,11 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > case FFA_PARTITION_INFO_GET:
> > do_ffa_part_get(&res, host_ctxt);
> > goto out_handled;
> > + case FFA_MSG_SEND_DIRECT_REQ:
> > + case FFA_FN64_MSG_SEND_DIRECT_REQ:
> > +
>
> Weird whitespace addition ^^
>
Let me clear this space out.
> > + do_ffa_direct_msg(&res, host_ctxt, HOST_FFA_ID);
>
> What's the point of passing HOST_FFA_ID here? Is that supposed to end up
> in the Sender ID bits of W1?
I can remove it, this doesn't bring too much for upstream but on the
android kernel with guest-ffa it makes sense because we need to validate
the sender to prevent impersonation.
>
> Will
Thanks,
Sebastian
next prev parent reply other threads:[~2026-01-09 11:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 2:07 [PATCH v3 0/2] KVM: arm64: Support FF-A direct messaging interfaces Per Larsen via B4 Relay
2025-11-19 2:07 ` [PATCH v3 1/2] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in host handler Per Larsen via B4 Relay
2026-01-08 15:26 ` Will Deacon
2026-01-09 11:18 ` Sebastian Ene [this message]
2026-01-09 11:37 ` Will Deacon
2025-11-19 2:07 ` [PATCH v3 2/2] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ2 " Per Larsen via B4 Relay
2026-01-08 15:30 ` 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=aWDkCQ7m1-w8e-Py@google.com \
--to=sebastianene@google.com \
--cc=armellel@google.com \
--cc=ben.horgan@arm.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=oupton@kernel.org \
--cc=perlarsen@google.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yeoreum.yun@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