Re: [PATCH v3 1/2] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in host handler
From: Will Deacon <will@kernel.org>
Date: 2026-01-09 11:37:34
Also in:
kvmarm, lkml
Hey Seb, Cheers for the reply. On Fri, Jan 09, 2026 at 11:18:33AM +0000, Sebastian Ene wrote:
On Thu, Jan 08, 2026 at 03:26:21PM +0000, Will Deacon wrote:quoted
On Wed, Nov 19, 2025 at 02:07:53AM +0000, Per Larsen via B4 Relay wrote:quoted
From: Sebastian Ene <redacted> 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 <redacted> Reviewed-by: Yeoreum Yun <redacted> Signed-off-by: Per Larsen <redacted> --- 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.
I think it would also be more robust if new messaging types are added in future, as we would fail safe.
quoted
quoted
+ 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.
We could also validate that the sender is HOST_FFA_ID in this case, but that seems to be missing atm. Cheers, Will