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: 10+ 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
2025-11-19 2:07 ` 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
2025-11-19 2:07 ` 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
2025-11-19 2:07 ` 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 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.