[PATCH v7 0/3] KVM: arm64: Support FF-A direct messaging interfaces

[PATCH v7 0/3] KVM: arm64: Support FF-A direct messaging interfaces

[Per Larsen via B4 Relay]

Block host-initiated FF-A direct responses.
Support FFA_MSG_SEND_DIRECT_REQ unconditionally.
Support FFA_MSG_SEND_DIRECT_REQ2 if hypervisor negotiated version 1.2+.

Framework messages (FF-A control plane) are filtered out. For
FFA_MSG_SEND_DIRECT_REQ, we look at flags in w2. Messages using the REQ2
interface are always partition messages.

The third patch was part of a previous patch set [0] but was dropped
since the use case was unclear. A clear use case has now appeared: use
TPM device with CRB over FF-A when kernel boots with pkvm [1].

Tested by booting Android under QEMU.

Best Regards,
Per

[0]: https://lore.kernel.org/all/20250730-virtio-msg-ffa-v9-0-7f1b55c8d149@google.com/
[1]: https://lore.kernel.org/all/20251027191729.1704744-1-yeoreum.yun@arm.com/

Signed-off-by: Per Larsen <perlarsen@google.com>
---
Changes in v7:
- New patch 1/3: block FFA_FN64_MSG_SEND_DIRECT_RESP. Only the 32-bit
  variant was denied, so the host could send unvalidated 64-bit direct
  responses to EL3, including a forged sender endpoint ID
- Use hyp_smccc_1_2_smc() so the call is bracketed by hyp_exit/hyp_enter;
  the pass-through path already traced these calls
- Declare endp/flags as u64 and reject a non-zero x1[63:32]: these are
  w1/w2, but the raw 64-bit registers are forwarded to EL3
- Pass the canonicalised func_id to do_ffa_direct_msg() rather than
  re-reading x0, which still carries ARM_SMCCC_CALL_HINTS
- Link to v6: https://lore.kernel.org/r/20260501-host-direct-messages-v6-0-3f4af727ed85@google.com

Changes in v6:
- 1/2: validate that bits 31:16 of w1 is HOST_FFA_ID.
- Link to v5: https://lore.kernel.org/r/20260121-host-direct-messages-v5-0-2c1614c94e80@google.com

Changes in v5:
- 1/2: do_ffa_direct_msg: validate that sender is HOST_FFA_ID.
- Link to v4: https://lore.kernel.org/r/20260109-host-direct-messages-v4-0-95da4221d186@google.com

Changes in v4:
- 1/2: do_ffa_direct_msg: check that flag in w2 is zero; drop unused vm_handle parameter.
- 2/2: ffa_call_supported: simplify logic by reordering cases.
-      do_ffa_direct_msg: switch polarity of check and update comment.
- Link to v3: https://lore.kernel.org/r/20251119-host-direct-messages-v3-0-c74d04944b26@google.com

Changes in v3:
- Filter out framework messages as suggested by Will Deacon. Update cover letter accordingly.
- Update trailers: Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
- Link to v2: https://lore.kernel.org/r/20251030-host-direct-messages-v2-0-9f27cef36730@google.com

Changes in v2:
- 1/2: Drop support for FFA_ID_GET interface in host handler.
- Link to v1: https://lore.kernel.org/r/20251030-host-direct-messages-v1-0-463e57871c8f@google.com

---
Per Larsen (2):
      KVM: arm64: Block host-initiated FF-A direct responses
      KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ2 in host handler

Sebastian Ene (1):
      KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in host handler

 arch/arm64/kvm/hyp/nvhe/ffa.c | 44 +++++++++++++++++++++++++++++++++++++++++--
 include/linux/arm_ffa.h       |  2 ++
 2 files changed, 44 insertions(+), 2 deletions(-)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20251029-host-direct-messages-5201d7f55abd

Best regards,
-- 
Per Larsen <perlarsen@google.com>

[PATCH v7 1/3] KVM: arm64: Block host-initiated FF-A direct responses

[Per Larsen via B4 Relay]

From: Per Larsen <perlarsen@google.com>

ffa_call_supported() rejects FFA_MSG_SEND_DIRECT_RESP, but allows
FFA_FN64_MSG_SEND_DIRECT_RESP to be forwarded to firmware.

The host is never the target of an FF-A direct request and therefore
cannot initiate a direct response. Reject both calling conventions.

Suggested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Per Larsen <perlarsen@google.com>
---
 arch/arm64/kvm/hyp/nvhe/ffa.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index a327c2bbb6b6..9e8bb95e8845 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -686,8 +686,10 @@ static bool ffa_call_supported(u64 func_id)
 	case FFA_MSG_SEND:
 	case FFA_MSG_POLL:
 	case FFA_MSG_WAIT:
-	/* 32-bit variants of 64-bit calls */
+	/* The host is never the target of a direct request */
 	case FFA_MSG_SEND_DIRECT_RESP:
+	case FFA_FN64_MSG_SEND_DIRECT_RESP:
+	/* 32-bit variants of 64-bit calls */
 	case FFA_RXTX_MAP:
 	case FFA_MEM_DONATE:
 	case FFA_MEM_RETRIEVE_REQ:

-- 
2.55.0.897.gb25b4bd76c-goog

[PATCH v7 2/3] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in host handler

[Per Larsen via B4 Relay]

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 | 27 +++++++++++++++++++++++++++
 include/linux/arm_ffa.h       |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 9e8bb95e8845..96cf6be969de 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -880,6 +880,29 @@ 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)
+{
+	DECLARE_REG(u64, endp, ctxt, 1);
+	DECLARE_REG(u64, flags, ctxt, 2);
+
+	struct arm_smccc_1_2_regs *args = (void *)&ctxt->regs.regs[0];
+
+	if (upper_32_bits(endp) ||
+	    FIELD_GET(FFA_SRC_ENDPOINT_MASK, endp) != HOST_FFA_ID) {
+		ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
+		return;
+	}
+
+	/* filter out framework messages and validate SBZ/MBZ bits */
+	if (flags) {
+		ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
+		return;
+	}
+
+	hyp_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 = {0};
@@ -938,6 +961,10 @@ 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:
+		do_ffa_direct_msg(&res, host_ctxt);
+		goto out_handled;
 	}
 
 	if (ffa_call_supported(func_id))
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index e71d83ee0aef..a3f44e7c08de 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -269,6 +269,8 @@ bool ffa_partition_check_property(struct ffa_device *dev, u32 property)
 	(ffa_partition_check_property(dev, FFA_PARTITION_DIRECT_REQ2_RECV) && \
 	 !dev->mode_32bit)
 
+#define FFA_SRC_ENDPOINT_MASK	GENMASK(31, 16)
+
 /* For use with FFA_MSG_SEND_DIRECT_{REQ,RESP} which pass data via registers */
 struct ffa_send_direct_data {
 	unsigned long data0; /* w3/x3 */

-- 
2.55.0.897.gb25b4bd76c-goog

[PATCH v7 3/3] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ2 in host handler

[Per Larsen via B4 Relay]

From: Per Larsen <perlarsen@google.com>

FF-A 1.2 adds the DIRECT_REQ2 messaging interface which is similar to
the existing FFA_MSG_SEND_DIRECT_{REQ,RESP} functions and can use the
existing handler function. Add support for FFA_MSG_SEND_DIRECT_REQ2 in
the host ffa handler.

Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Per Larsen <perlarsen@google.com>
---
 arch/arm64/kvm/hyp/nvhe/ffa.c | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 96cf6be969de..eeb8d5b6f3e0 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -702,11 +702,12 @@ static bool ffa_call_supported(u64 func_id)
 	case FFA_NOTIFICATION_GET:
 	case FFA_NOTIFICATION_INFO_GET:
 	/* Optional interfaces added in FF-A 1.2 */
-	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
 	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */
 	case FFA_CONSOLE_LOG:			/* Optional per 13.1: not in Table 13.1 */
 	case FFA_PARTITION_INFO_GET_REGS:	/* Optional for virtual instances per 13.1 */
 		return false;
+	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
+		return hyp_ffa_version >= FFA_VERSION_1_2;
 	}
 
 	return true;
@@ -880,7 +881,8 @@ 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,
+static void do_ffa_direct_msg(const u64 func_id,
+			      struct arm_smccc_1_2_regs *res,
 			      struct kvm_cpu_context *ctxt)
 {
 	DECLARE_REG(u64, endp, ctxt, 1);
@@ -894,8 +896,12 @@ static void do_ffa_direct_msg(struct arm_smccc_1_2_regs *res,
 		return;
 	}
 
-	/* filter out framework messages and validate SBZ/MBZ bits */
-	if (flags) {
+	/*
+	 * filter out framework messages and validate SBZ/MBZ flag bits.
+	 * FFA_MSG_SEND_DIRECT_REQ2 implies flag-less partition message.
+	 */
+	if ((func_id == FFA_MSG_SEND_DIRECT_REQ ||
+	     func_id == FFA_FN64_MSG_SEND_DIRECT_REQ) && flags) {
 		ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
 		return;
 	}
@@ -961,15 +967,20 @@ 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_REQ2:
+		if (!ffa_call_supported(func_id))
+			goto out_not_supported;
+		fallthrough;
 	case FFA_MSG_SEND_DIRECT_REQ:
 	case FFA_FN64_MSG_SEND_DIRECT_REQ:
-		do_ffa_direct_msg(&res, host_ctxt);
+		do_ffa_direct_msg(func_id, &res, host_ctxt);
 		goto out_handled;
 	}
 
 	if (ffa_call_supported(func_id))
 		return false; /* Pass through */
 
+out_not_supported:
 	ffa_to_smccc_error(&res, FFA_RET_NOT_SUPPORTED);
 out_handled:
 	ffa_set_retval(host_ctxt, &res);

-- 
2.55.0.897.gb25b4bd76c-goog

Re: [PATCH v7 1/3] KVM: arm64: Block host-initiated FF-A direct responses

[Fuad Tabba]

Hi Per,

On Mon, 31 Aug 2026 at 00:08, Per Larsen via B4 Relay
<devnull+perlarsen.google.com@kernel.org> wrote:
...
> @@ -686,8 +686,10 @@ static bool ffa_call_supported(u64 func_id)
>   case FFA_MSG_SEND:
>   case FFA_MSG_POLL:
>   case FFA_MSG_WAIT:
> - /* 32-bit variants of 64-bit calls */
> + /* The host is never the target of a direct request */
>   case FFA_MSG_SEND_DIRECT_RESP:
> + case FFA_FN64_MSG_SEND_DIRECT_RESP:
> + /* 32-bit variants of 64-bit calls */
>   case FFA_RXTX_MAP:
>   case FFA_MEM_DONATE:
>   case FFA_MEM_RETRIEVE_REQ:

Sashiko asked whether the interfaces it listed should be added to the
blocklist too. For FFA_FN64_NOTIFICATION_INFO_GET the answer looks
like yes: FFA_FN_NATIVE() is FFA_FN64_##name on arm64, and
ffa_notification_info_get() is the only in-tree caller, so the 32-bit
entry a few lines below never matches what the host sends. Could you
add it here?

The other three aren't the same case. FFA_RX_RELEASE has to keep going
through, since the host's release is what frees the hypervisor's RX
buffer after do_ffa_part_get().

Cheers,
/fuad

Re: [PATCH v7 2/3] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in host handler

[Fuad Tabba]

Hi Per, Seb,

On Mon, 31 Aug 2026 at 00:08, Per Larsen via B4 Relay
<devnull+perlarsen.google.com@kernel.org> wrote:
[...]
> Allow direct messages to be forwarded from the host. The host should
> not be sending framework messages so they are filtered out.

The patch also rejects a sender ID that isn't HOST_FFA_ID, which the
message doesn't mention. Could you add a line for it?

[...]

> + if (upper_32_bits(endp) ||
> +    FIELD_GET(FFA_SRC_ENDPOINT_MASK, endp) != HOST_FFA_ID) {

Rejecting a non-zero high half of x1 makes sense to me, since EL2
checks bits 31:16 and then forwards the whole register to EL3, and
handle_host_smc() already does the same for x0. x3 to x17 reach EL3 as
the host wrote them though. Was the intent to stop at the registers
this function reads?

[...]

> + struct arm_smccc_1_2_regs *args = (void *)&ctxt->regs.regs[0];

This relies on struct arm_smccc_1_2_regs fitting in the 31 entries of
regs[], which holds today at 18. Could it take a BUILD_BUG_ON, like
do_ffa_mem_xfer() has for its fids?

Cheers,
/fuad

Re: [PATCH v7 3/3] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ2 in host handler

[Fuad Tabba]

Hi Per,

On Mon, 31 Aug 2026 at 00:08, Per Larsen via B4 Relay
<devnull+perlarsen.google.com@kernel.org> wrote:
...
> -static void do_ffa_direct_msg(struct arm_smccc_1_2_regs *res,
> +static void do_ffa_direct_msg(const u64 func_id,
> +                             struct arm_smccc_1_2_regs *res,
>                               struct kvm_cpu_context *ctxt)
>  {
>         DECLARE_REG(u64, endp, ctxt, 1);
> @@ -894,8 +896,12 @@ static void do_ffa_direct_msg(struct arm_smccc_1_2_regs *res,
>                 return;
>         }
>
> -       /* filter out framework messages and validate SBZ/MBZ bits */
> -       if (flags) {
> +       /*
> +        * filter out framework messages and validate SBZ/MBZ flag bits.
> +        * FFA_MSG_SEND_DIRECT_REQ2 implies flag-less partition message.
> +        */
> +       if ((func_id == FFA_MSG_SEND_DIRECT_REQ ||
> +            func_id == FFA_FN64_MSG_SEND_DIRECT_REQ) && flags) {
>                 ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
>                 return;

flags holds x2, which on the REQ2 path is the UUID's low half, so the
name reads as if REQ2 flags had been checked and found zero. Could it
be w2 instead?

Cheers,
/fuad


>         }
> @@ -961,15 +967,20 @@ 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_REQ2:
> +               if (!ffa_call_supported(func_id))
> +                       goto out_not_supported;
> +               fallthrough;
>         case FFA_MSG_SEND_DIRECT_REQ:
>         case FFA_FN64_MSG_SEND_DIRECT_REQ:
> -               do_ffa_direct_msg(&res, host_ctxt);
> +               do_ffa_direct_msg(func_id, &res, host_ctxt);
>                 goto out_handled;
>         }
>
>         if (ffa_call_supported(func_id))
>                 return false; /* Pass through */
>
> +out_not_supported:
>         ffa_to_smccc_error(&res, FFA_RET_NOT_SUPPORTED);
>  out_handled:
>         ffa_set_retval(host_ctxt, &res);
>
> --
> 2.55.0.897.gb25b4bd76c-goog
>
>

Re: [PATCH v7 0/3] KVM: arm64: Support FF-A direct messaging interfaces

[Fuad Tabba]

Hi Per,

On Mon, 31 Aug 2026 at 00:08, Per Larsen via B4 Relay
<devnull+perlarsen.google.com@kernel.org> wrote:
>
> Block host-initiated FF-A direct responses.
> Support FFA_MSG_SEND_DIRECT_REQ unconditionally.
> Support FFA_MSG_SEND_DIRECT_REQ2 if hypervisor negotiated version 1.2+.
>
> Framework messages (FF-A control plane) are filtered out. For
> FFA_MSG_SEND_DIRECT_REQ, we look at flags in w2. Messages using the REQ2
> interface are always partition messages.
>
> The third patch was part of a previous patch set [0] but was dropped
> since the use case was unclear. A clear use case has now appeared: use
> TPM device with CRB over FF-A when kernel boots with pkvm [1].

tpm_crb_ffa already uses sync_send_receive2() for partitions that
support REQ2, and on a pKVM host that returns -EOPNOTSUPP today: the
FF-A driver sets msg_direct_req2_supp when either FFA_FEATURES(REQ2)
or FFA_FEATURES(RESP2) succeeds, and before patch 3 the hypervisor
answers NOT_SUPPORTED to both. Patch 3 lets the REQ2 query through to
firmware, which is enough for the OR. Worth citing that in the cover
instead of [1]?

> Tested by booting Android under QEMU.

Which firmware was that, and what did it negotiate for FFA_VERSION?
The proxy doesn't initialise unless firmware answers that call, so I'd
like to know whether a REQ2 in particular round-tripped.

>
> Best Regards,
> Per
>
> [0]: https://lore.kernel.org/all/20250730-virtio-msg-ffa-v9-0-7f1b55c8d149@google.com/
> [1]: https://lore.kernel.org/all/20251027191729.1704744-1-yeoreum.yun@arm.com/
>
> Signed-off-by: Per Larsen <perlarsen@google.com>
> ---
> Changes in v7:
> - New patch 1/3: block FFA_FN64_MSG_SEND_DIRECT_RESP. Only the 32-bit
>   variant was denied, so the host could send unvalidated 64-bit direct
>   responses to EL3, including a forged sender endpoint ID
> - Use hyp_smccc_1_2_smc() so the call is bracketed by hyp_exit/hyp_enter;
>   the pass-through path already traced these calls
> - Declare endp/flags as u64 and reject a non-zero x1[63:32]: these are
>   w1/w2, but the raw 64-bit registers are forwarded to EL3
> - Pass the canonicalised func_id to do_ffa_direct_msg() rather than
>   re-reading x0, which still carries ARM_SMCCC_CALL_HINTS
> - Link to v6: https://lore.kernel.org/r/20260501-host-direct-messages-v6-0-3f4af727ed85@google.com
>
> Changes in v6:
> - 1/2: validate that bits 31:16 of w1 is HOST_FFA_ID.
> - Link to v5: https://lore.kernel.org/r/20260121-host-direct-messages-v5-0-2c1614c94e80@google.com
>
> Changes in v5:
> - 1/2: do_ffa_direct_msg: validate that sender is HOST_FFA_ID.
> - Link to v4: https://lore.kernel.org/r/20260109-host-direct-messages-v4-0-95da4221d186@google.com
>
> Changes in v4:
> - 1/2: do_ffa_direct_msg: check that flag in w2 is zero; drop unused vm_handle parameter.
> - 2/2: ffa_call_supported: simplify logic by reordering cases.
> -      do_ffa_direct_msg: switch polarity of check and update comment.
> - Link to v3: https://lore.kernel.org/r/20251119-host-direct-messages-v3-0-c74d04944b26@google.com
>
> Changes in v3:
> - Filter out framework messages as suggested by Will Deacon. Update cover letter accordingly.
> - Update trailers: Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> - Link to v2: https://lore.kernel.org/r/20251030-host-direct-messages-v2-0-9f27cef36730@google.com
>
> Changes in v2:
> - 1/2: Drop support for FFA_ID_GET interface in host handler.
> - Link to v1: https://lore.kernel.org/r/20251030-host-direct-messages-v1-0-463e57871c8f@google.com
>
> ---
> Per Larsen (2):
>       KVM: arm64: Block host-initiated FF-A direct responses
>       KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ2 in host handler
>
> Sebastian Ene (1):
>       KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in host handler
>
>  arch/arm64/kvm/hyp/nvhe/ffa.c | 44 +++++++++++++++++++++++++++++++++++++++++--
>  include/linux/arm_ffa.h       |  2 ++
>  2 files changed, 44 insertions(+), 2 deletions(-)
> ---
> base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
> change-id: 20251029-host-direct-messages-5201d7f55abd
>
> Best regards,
> --
> Per Larsen <perlarsen@google.com>
>
>

Re: [PATCH v7 2/3] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in host handler

[Vincent Donnefort]

On Sun, Aug 30, 2026 at 11:08:14PM +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 | 27 +++++++++++++++++++++++++++
>  include/linux/arm_ffa.h       |  2 ++
>  2 files changed, 29 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 9e8bb95e8845..96cf6be969de 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -880,6 +880,29 @@ 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)
> +{
> +	DECLARE_REG(u64, endp, ctxt, 1);
> +	DECLARE_REG(u64, flags, ctxt, 2);
> +
> +	struct arm_smccc_1_2_regs *args = (void *)&ctxt->regs.regs[0];


For a next version, ffa_check_unused_args_sbz() has just been merged. [1]

[1] https://lore.kernel.org/all/20260907171930.4037166-8-sebastianene@google.com/

-- 
Vincent

> +
> +	if (upper_32_bits(endp) ||
> +	    FIELD_GET(FFA_SRC_ENDPOINT_MASK, endp) != HOST_FFA_ID) {
> +		ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
> +		return;
> +	}
> +
> +	/* filter out framework messages and validate SBZ/MBZ bits */
> +	if (flags) {
> +		ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
> +		return;
> +	}
> +
> +	hyp_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 = {0};
> @@ -938,6 +961,10 @@ 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:
> +		do_ffa_direct_msg(&res, host_ctxt);
> +		goto out_handled;
>  	}
>  
>  	if (ffa_call_supported(func_id))
> diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
> index e71d83ee0aef..a3f44e7c08de 100644
> --- a/include/linux/arm_ffa.h
> +++ b/include/linux/arm_ffa.h
> @@ -269,6 +269,8 @@ bool ffa_partition_check_property(struct ffa_device *dev, u32 property)
>  	(ffa_partition_check_property(dev, FFA_PARTITION_DIRECT_REQ2_RECV) && \
>  	 !dev->mode_32bit)
>  
> +#define FFA_SRC_ENDPOINT_MASK	GENMASK(31, 16)
> +
>  /* For use with FFA_MSG_SEND_DIRECT_{REQ,RESP} which pass data via registers */
>  struct ffa_send_direct_data {
>  	unsigned long data0; /* w3/x3 */
> 
> -- 
> 2.55.0.897.gb25b4bd76c-goog
> 
> 
>