[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aXNvzxoBXr-oRB8r@willie-the-truck>
Date: Fri, 23 Jan 2026 12:55:43 +0000
From: Will Deacon <will@...nel.org>
To: perlarsen@...gle.com
Cc: Marc Zyngier <maz@...nel.org>, Joey Gouly <joey.gouly@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Zenghui Yu <yuzenghui@...wei.com>,
Catalin Marinas <catalin.marinas@....com>,
Yeoreum Yun <yeoreum.yun@....com>, Ben Horgan <ben.horgan@....com>,
Oliver Upton <oupton@...nel.org>,
Armelle Laine <armellel@...gle.com>,
Sebastien Ene <sebastianene@...gle.com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/2] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in
host handler
Per,
On Wed, Jan 21, 2026 at 08:27:12AM +0000, Per Larsen via B4 Relay wrote:
> From: Sebastian Ene <sebastianene@...gle.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@...gle.com>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@....com>
> Signed-off-by: Per Larsen <perlarsen@...gle.com>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index f731cc4c3f280a32acccca0de92b9ac6c8e05602..9967916278a7ca051500946ef2fcfe7bb40e0e8d 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -862,6 +862,28 @@ 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];
> +
> + if (vm_handle != HOST_FFA_ID) {
> + ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
Sorry, but this isn't what I had in mind. 'vm_handle' is just a local
variable and the only caller passes HOST_FFA_ID, so this isn't really
achieving anything.
What you had in v4 dropped the 'vm_handle' argument entirely, which I
think is the right thing to do. However, the FF-A spec encodes the sender
ID in bits 31:16 of register W1 and so _that_ is what I think we should
be checking because _that_ is what the receiver will see.
Honestly, we could avoid quite a lot of these review cycles if you
actually replied to my emails on the list instead of just responding
with a new patch series each time. It's supposed to be a technical
discussion...
Will
Powered by blists - more mailing lists