[PATCH 0/2] KVM: arm64: Support FFA_FN64_MEM_RECLAIM2 in host handler

[PATCH 0/2] KVM: arm64: Support FFA_FN64_MEM_RECLAIM2 in host handler

[Snehal Koukuntla]

The Arm Firmware Framework for Arm A-profile (FF-A) v1.3 ALP5
specification (DEN0140 rev J) [1] introduces the optional
FFA_MEM_RECLAIM2 (0xC4000091) ABI.

Reclaiming large memory regions with the existing FFA_MEM_RECLAIM ABI
can take significant time, or relies on a stateful time-slicing
mechanism in the Relayer. FFA_MEM_RECLAIM2 allows an Owner to reclaim
exclusive access to a subset of pages from a shared or lent memory
region by passing an array of constituent memory region descriptors in
its TX buffer along with a starting descriptor byte offset and initial
page index. The Relayer returns the number of 4K pages reclaimed in
that invocation without maintaining intermediate transaction state.

This series adds the FFA_FN64_MEM_RECLAIM2 function ID definition and
implements host proxy support in the pKVM nVHE FF-A handler, unsharing
the reclaimed pages in the host stage-2 page tables upon a successful
reclaim response from EL3/SPMD.

This series is based on kvmarm/next, as Patch 2 uses
ffa_check_unused_args_sbz() introduced in commit 3e9df0b0ebd5
("KVM: arm64: Enforce strict SBZ checks in the FF-A proxy").

[1] https://support.arm.com/documentation/den0140/j

Snehal Koukuntla (2):
  firmware: arm_ffa: Add FFA_FN64_MEM_RECLAIM2 function ID
  KVM: arm64: Support FFA_FN64_MEM_RECLAIM2 in host handler

 arch/arm64/kvm/hyp/nvhe/ffa.c | 117 ++++++++++++++++++++++++++++++++++
 include/linux/arm_ffa.h       |   1 +
 2 files changed, 118 insertions(+)


base-commit: 23ddf997ab16b5f4aa9f948f5a68f5b35e4e398f
-- 
2.55.0.1082.g2b9226bbc0-goog

[PATCH 1/2] firmware: arm_ffa: Add FFA_FN64_MEM_RECLAIM2 function ID

[Snehal Koukuntla]

FF-A v1.3 ALP5 (DEN0140 rev J) introduces the optional FFA_MEM_RECLAIM2
(0xC4000091) ABI, which enables an Owner to reclaim exclusive access to
a subset of pages of a memory region without requiring the Relayer to
maintain intermediate transaction state.

Add the FFA_FN64_MEM_RECLAIM2 function ID definition to arm_ffa.h.

Link: https://support.arm.com/documentation/den0140/j
Signed-off-by: Snehal Koukuntla <snehalreddy@google.com>
---
 include/linux/arm_ffa.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index e71d83ee0aef..c78cfd72832a 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -78,6 +78,7 @@
 #define FFA_EL3_INTR_HANDLE		FFA_SMC_32(0x8C)
 #define FFA_MSG_SEND_DIRECT_REQ2	FFA_SMC_64(0x8D)
 #define FFA_MSG_SEND_DIRECT_RESP2	FFA_SMC_64(0x8E)
+#define FFA_FN64_MEM_RECLAIM2		FFA_SMC_64(0x91)
 
 /*
  * For some calls it is necessary to use SMC64 to pass or return 64-bit values.
-- 
2.55.0.1082.g2b9226bbc0-goog

[PATCH 2/2] KVM: arm64: Support FFA_FN64_MEM_RECLAIM2 in host handler

[Snehal Koukuntla]

FF-A v1.3 ALP5 (DEN0140 rev J) adds the FFA_MEM_RECLAIM2 interface,
allowing an Owner to reclaim a subset of pages from a shared or lent
memory region by populating constituent memory region descriptors in
its TX buffer along with a starting descriptor byte offset and initial
page index. Upon completion, the Relayer returns the number of 4K pages
reclaimed in x3.

Support FFA_FN64_MEM_RECLAIM2 in the host FF-A proxy handler. Validate
the register arguments, descriptor bounds, and initial page index
against the host TX buffer before forwarding the SMC call to the SPMD,
and unshare the reclaimed page ranges in the host stage-2 page tables.

Link: https://support.arm.com/documentation/den0140/j
Signed-off-by: Snehal Koukuntla <snehalreddy@google.com>
---
 arch/arm64/kvm/hyp/nvhe/ffa.c | 117 ++++++++++++++++++++++++++++++++++
 1 file changed, 117 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 5ad74ab265b5..e0fba07a67bc 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -232,6 +232,19 @@ static void ffa_mem_reclaim(struct arm_smccc_1_2_regs *res, u32 handle_lo,
 	}, res);
 }
 
+static void ffa_mem_reclaim2(struct arm_smccc_1_2_regs *res, u64 handle,
+			     u64 flags, u64 x3, u64 x4, u64 x5)
+{
+	hyp_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
+		.a0 = FFA_FN64_MEM_RECLAIM2,
+		.a1 = handle,
+		.a2 = flags,
+		.a3 = x3,
+		.a4 = x4,
+		.a5 = x5,
+	}, res);
+}
+
 static void ffa_retrieve_req(struct arm_smccc_1_2_regs *res, u32 len)
 {
 	hyp_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
@@ -611,6 +624,107 @@ static void __do_ffa_mem_xfer(const u64 func_id,
 		__do_ffa_mem_xfer((fid), (res), (ctxt));	\
 	} while (0);
 
+static void do_ffa_mem_reclaim2(struct arm_smccc_1_2_regs *res,
+				struct kvm_cpu_context *ctxt)
+{
+	DECLARE_REG(u64, handle, ctxt, 1);
+	DECLARE_REG(u64, flags, ctxt, 2);
+	DECLARE_REG(u64, x3, ctxt, 3);
+	DECLARE_REG(u64, x4, ctxt, 4);
+	DECLARE_REG(u64, x5, ctxt, 5);
+	u32 req_desc_cnt = (u32)(x3 >> 32);
+	u32 total_pages = (u32)x3;
+	u32 desc_size = (u32)x4;
+	u32 offset = (u32)x5;
+	u32 page_index = (u32)(x5 >> 32);
+	struct ffa_mem_region_addr_range *range;
+	u32 reclaimed_pages;
+	u32 reclaimed_count = 0;
+	u32 in_idx;
+	int ret = 0;
+
+	if (ffa_check_unused_args_sbz(ctxt, 6) || (flags & ~1ULL) || (x4 >> 32)) {
+		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+		return;
+	}
+
+	if (!req_desc_cnt || !total_pages) {
+		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+		return;
+	}
+
+	if (desc_size != sizeof(struct ffa_mem_region_addr_range)) {
+		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+		return;
+	}
+
+	if ((u64)req_desc_cnt * desc_size > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
+		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+		return;
+	}
+
+	if (offset % desc_size != 0) {
+		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+		return;
+	}
+
+	if (offset >= (u64)req_desc_cnt * desc_size) {
+		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+		return;
+	}
+
+	hyp_spin_lock(&host_buffers.lock);
+	if (!host_buffers.tx) {
+		ret = FFA_RET_INVALID_PARAMETERS;
+		goto out_unlock;
+	}
+
+	memcpy(hyp_buffers.tx, host_buffers.tx, (u64)req_desc_cnt * desc_size);
+
+	range = (void *)hyp_buffers.tx + offset;
+	if (page_index >= range->pg_cnt) {
+		ret = FFA_RET_INVALID_PARAMETERS;
+		goto out_unlock;
+	}
+
+	ffa_mem_reclaim2(res, handle, flags, x3, x4, x5);
+	if (res->a0 != FFA_SUCCESS)
+		goto out_unlock;
+
+	reclaimed_pages = res->a3;
+
+	for (in_idx = offset / desc_size; in_idx < req_desc_cnt; in_idx++) {
+		struct ffa_mem_region_addr_range temp;
+		u32 pg_cnt, to_reclaim;
+
+		if (reclaimed_count >= reclaimed_pages)
+			break;
+
+		range = (void *)hyp_buffers.tx + in_idx * desc_size;
+		if (!range->pg_cnt)
+			continue;
+
+		pg_cnt = range->pg_cnt - page_index;
+		to_reclaim = min(pg_cnt, reclaimed_pages - reclaimed_count);
+
+		temp = (struct ffa_mem_region_addr_range) {
+			.address = range->address + (u64)page_index * FFA_PAGE_SIZE,
+			.pg_cnt = to_reclaim,
+		};
+
+		WARN_ON(ffa_host_unshare_ranges(&temp, 1));
+
+		reclaimed_count += to_reclaim;
+		page_index = 0;
+	}
+
+out_unlock:
+	hyp_spin_unlock(&host_buffers.lock);
+
+	if (ret)
+		ffa_to_smccc_res(res, ret);
+}
+
 static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
 			       struct kvm_cpu_context *ctxt)
 {
@@ -1107,6 +1221,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
 	case FFA_MEM_RECLAIM:
 		do_ffa_mem_reclaim(&res, host_ctxt);
 		goto out_handled;
+	case FFA_FN64_MEM_RECLAIM2:
+		do_ffa_mem_reclaim2(&res, host_ctxt);
+		goto out_handled;
 	case FFA_MEM_LEND:
 	case FFA_FN64_MEM_LEND:
 		do_ffa_mem_xfer(FFA_FN64_MEM_LEND, &res, host_ctxt);
-- 
2.55.0.1082.g2b9226bbc0-goog

Re: [PATCH 1/2] firmware: arm_ffa: Add FFA_FN64_MEM_RECLAIM2 function ID

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] arm_ffa: missing 32-bit counterpart for FFA_FN64_MEM_RECLAIM2
--

commit b51b8a72f11f56713926464f6a895ddb89b963d1
Author: Snehal Koukuntla <snehalreddy@google.com>

firmware: arm_ffa: Add FFA_FN64_MEM_RECLAIM2 function ID

This commit introduces the FFA_FN64_MEM_RECLAIM2 function ID in arm_ffa.h
to support the FFA_MEM_RECLAIM2 ABI introduced in FF-A v1.3 ALP5. This ABI
allows an owner to reclaim exclusive access to pages without requiring
intermediate transaction state maintenance.

Link: https://support.arm.com/documentation/den0140/j

> diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
> index e71d83ee0aef3..c78cfd72832a7 100644
> --- a/include/linux/arm_ffa.h
> +++ b/include/linux/arm_ffa.h
> @@ -78,6 +78,7 @@
>  #define FFA_EL3_INTR_HANDLE		FFA_SMC_32(0x8C)
>  #define FFA_MSG_SEND_DIRECT_REQ2	FFA_SMC_64(0x8D)
>  #define FFA_MSG_SEND_DIRECT_RESP2	FFA_SMC_64(0x8E)
> +#define FFA_FN64_MEM_RECLAIM2		FFA_SMC_64(0x91)

[Severity: Low]
Does the missing 32-bit counterpart for FFA_FN64_MEM_RECLAIM2 break
FFA_FN_NATIVE() compatibility on 32-bit architectures?

Every other FFA_FN64_ prefix in the header has a 32-bit counterpart. If
FFA_FN_NATIVE(MEM_RECLAIM2) is ever used on a 32-bit build, it will evaluate
to FFA_MEM_RECLAIM2 due to the architecture-conditional logic, which does
not exist here, and would cause a compilation failure.

For 64-bit exclusive ABIs like FFA_MSG_SEND_DIRECT_REQ2, the convention
is to omit the FN64_ prefix entirely.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921164748.2958578-1-snehalreddy@google.com?part=1

Re: [PATCH 2/2] KVM: arm64: Support FFA_FN64_MEM_RECLAIM2 in host handler

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: arm64: incorrect buffer bounds in do_ffa_mem_reclaim2()
--

commit 9e4ba2a6fb44613f009459976518be9371118818
Author: Snehal Koukuntla <snehalreddy@google.com>

KVM: arm64: Support FFA_FN64_MEM_RECLAIM2 in host handler

This commit adds support for the FFA_MEM_RECLAIM2 interface in the host
FF-A proxy handler. It forwards the SMC call to the SPMD and unshares the
reclaimed page ranges in the host stage-2 page tables.

Link: https://support.arm.com/documentation/den0140/j

> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 5ad74ab265b57..e0fba07a67bc9 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
[ ... ]
> @@ -611,6 +624,107 @@ static void __do_ffa_mem_xfer(const u64 func_id,
[ ... ]
> +static void do_ffa_mem_reclaim2(struct arm_smccc_1_2_regs *res,
> +				struct kvm_cpu_context *ctxt)
> +{
> +	DECLARE_REG(u64, handle, ctxt, 1);
> +	DECLARE_REG(u64, flags, ctxt, 2);
> +	DECLARE_REG(u64, x3, ctxt, 3);
> +	DECLARE_REG(u64, x4, ctxt, 4);
> +	DECLARE_REG(u64, x5, ctxt, 5);
> +	u32 req_desc_cnt = (u32)(x3 >> 32);
> +	u32 total_pages = (u32)x3;
> +	u32 desc_size = (u32)x4;
> +	u32 offset = (u32)x5;
> +	u32 page_index = (u32)(x5 >> 32);
[ ... ]
> +	if (offset >= (u64)req_desc_cnt * desc_size) {
> +		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> +		return;
> +	}

[Severity: High]
Could this check incorrectly reject valid offsets? By checking offset against
the total length of the requested descriptors (req_desc_cnt * desc_size), it
seems to conflate the descriptor count with the total buffer capacity.

> +
> +	hyp_spin_lock(&host_buffers.lock);
> +	if (!host_buffers.tx) {
> +		ret = FFA_RET_INVALID_PARAMETERS;
> +		goto out_unlock;
> +	}
> +
> +	memcpy(hyp_buffers.tx, host_buffers.tx, (u64)req_desc_cnt * desc_size);

[Severity: High]
Is there a risk that this copies too few bytes when offset is greater than
zero? Since the start of the required descriptors in the buffer is shifted by
offset bytes, copying only req_desc_cnt * desc_size bytes from the beginning
of the host buffer misses the trailing descriptors.

If the host EL1 intentionally issues a hypercall with an offset greater than
zero, this might lead to the SPMD reading uninitialized or stale memory from
the hypervisor TX buffer.

> +
> +	range = (void *)hyp_buffers.tx + offset;
> +	if (page_index >= range->pg_cnt) {
> +		ret = FFA_RET_INVALID_PARAMETERS;
> +		goto out_unlock;
> +	}
> +
> +	ffa_mem_reclaim2(res, handle, flags, x3, x4, x5);
> +	if (res->a0 != FFA_SUCCESS)
> +		goto out_unlock;
> +
> +	reclaimed_pages = res->a3;
> +
> +	for (in_idx = offset / desc_size; in_idx < req_desc_cnt; in_idx++) {

[Severity: High]
Does this loop iterate fewer times than the number of descriptors reclaimed
by the SPMD?

Starting the loop index at offset / desc_size and ending it at req_desc_cnt
means the loop only executes (req_desc_cnt - offset / desc_size) times.
This appears to unshare fewer descriptors than the SPMD actually processed.

If the untrusted host EL1 triggers this path, it could leave the hypervisor
stage-2 ownership tracking permanently desynchronized from the SPMD state.

> +		struct ffa_mem_region_addr_range temp;
> +		u32 pg_cnt, to_reclaim;
> +
> +		if (reclaimed_count >= reclaimed_pages)
> +			break;
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921164748.2958578-1-snehalreddy@google.com?part=2

Re: [PATCH 2/2] KVM: arm64: Support FFA_FN64_MEM_RECLAIM2 in host handler

[Vincent Donnefort]

On Mon, Sep 21, 2026 at 04:47:48PM +0000, Snehal Koukuntla wrote:
> FF-A v1.3 ALP5 (DEN0140 rev J) adds the FFA_MEM_RECLAIM2 interface,
> allowing an Owner to reclaim a subset of pages from a shared or lent
> memory region by populating constituent memory region descriptors in
> its TX buffer along with a starting descriptor byte offset and initial
> page index. Upon completion, the Relayer returns the number of 4K pages
> reclaimed in x3.
> 
> Support FFA_FN64_MEM_RECLAIM2 in the host FF-A proxy handler. Validate
> the register arguments, descriptor bounds, and initial page index
> against the host TX buffer before forwarding the SMC call to the SPMD,
> and unshare the reclaimed page ranges in the host stage-2 page tables.
> 
> Link: https://support.arm.com/documentation/den0140/j
> Signed-off-by: Snehal Koukuntla <snehalreddy@google.com>
> ---
>  arch/arm64/kvm/hyp/nvhe/ffa.c | 117 ++++++++++++++++++++++++++++++++++
>  1 file changed, 117 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 5ad74ab265b5..e0fba07a67bc 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -232,6 +232,19 @@ static void ffa_mem_reclaim(struct arm_smccc_1_2_regs *res, u32 handle_lo,
>  	}, res);
>  }
>  
> +static void ffa_mem_reclaim2(struct arm_smccc_1_2_regs *res, u64 handle,
> +			     u64 flags, u64 x3, u64 x4, u64 x5)
> +{
> +	hyp_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
> +		.a0 = FFA_FN64_MEM_RECLAIM2,
> +		.a1 = handle,
> +		.a2 = flags,
> +		.a3 = x3,
> +		.a4 = x4,
> +		.a5 = x5,
> +	}, res);
> +}
> +
>  static void ffa_retrieve_req(struct arm_smccc_1_2_regs *res, u32 len)
>  {
>  	hyp_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
> @@ -611,6 +624,107 @@ static void __do_ffa_mem_xfer(const u64 func_id,
>  		__do_ffa_mem_xfer((fid), (res), (ctxt));	\
>  	} while (0);
>  
> +static void do_ffa_mem_reclaim2(struct arm_smccc_1_2_regs *res,
> +				struct kvm_cpu_context *ctxt)
> +{
> +	DECLARE_REG(u64, handle, ctxt, 1);
> +	DECLARE_REG(u64, flags, ctxt, 2);
> +	DECLARE_REG(u64, x3, ctxt, 3);
> +	DECLARE_REG(u64, x4, ctxt, 4);
> +	DECLARE_REG(u64, x5, ctxt, 5);
> +	u32 req_desc_cnt = (u32)(x3 >> 32);
> +	u32 total_pages = (u32)x3;
> +	u32 desc_size = (u32)x4;
> +	u32 offset = (u32)x5;
> +	u32 page_index = (u32)(x5 >> 32);
> +	struct ffa_mem_region_addr_range *range;
> +	u32 reclaimed_pages;
> +	u32 reclaimed_count = 0;
> +	u32 in_idx;
> +	int ret = 0;
> +
> +	if (ffa_check_unused_args_sbz(ctxt, 6) || (flags & ~1ULL) || (x4 >> 32)) {

nit: (flags > 1) ?

> +		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> +		return;
> +	}
> +
> +	if (!req_desc_cnt || !total_pages) {
> +		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> +		return;
> +	}
> +
> +	if (desc_size != sizeof(struct ffa_mem_region_addr_range)) {
> +		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> +		return;
> +	}
> +
> +	if ((u64)req_desc_cnt * desc_size > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
> +		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> +		return;
> +	}
> +
> +	if (offset % desc_size != 0) {

nit: 

if (offset % desc_size) is enough

> +		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> +		return;
> +	}
> +
> +	if (offset >= (u64)req_desc_cnt * desc_size) {
> +		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> +		return;
> +	}

Not sure I understand what Sashiko means here offset can not be bigger than the
number of constituents we have...

> +
> +	hyp_spin_lock(&host_buffers.lock);
> +	if (!host_buffers.tx) {
> +		ret = FFA_RET_INVALID_PARAMETERS;
> +		goto out_unlock;
> +	}
> +
> +	memcpy(hyp_buffers.tx, host_buffers.tx, (u64)req_desc_cnt * desc_size);

Either I or Sashiko is confused here. The invocation will not do more than
req_desc_cnt will it?

> +
> +	range = (void *)hyp_buffers.tx + offset;
> +	if (page_index >= range->pg_cnt) {
> +		ret = FFA_RET_INVALID_PARAMETERS;
> +		goto out_unlock;
> +	}

Should we also verify total_pages here?

> +
> +	ffa_mem_reclaim2(res, handle, flags, x3, x4, x5);
> +	if (res->a0 != FFA_SUCCESS)
> +		goto out_unlock;
> +
> +	reclaimed_pages = res->a3;
> +
> +	for (in_idx = offset / desc_size; in_idx < req_desc_cnt; in_idx++) {
> +		struct ffa_mem_region_addr_range temp;
> +		u32 pg_cnt, to_reclaim;
> +
> +		if (reclaimed_count >= reclaimed_pages)
> +			break;
> +
> +		range = (void *)hyp_buffers.tx + in_idx * desc_size;
> +		if (!range->pg_cnt)
> +			continue;
> +
> +		pg_cnt = range->pg_cnt - page_index;
> +		to_reclaim = min(pg_cnt, reclaimed_pages - reclaimed_count);
> +
> +		temp = (struct ffa_mem_region_addr_range) {
> +			.address = range->address + (u64)page_index * FFA_PAGE_SIZE,
> +			.pg_cnt = to_reclaim,
> +		};
> +
> +		WARN_ON(ffa_host_unshare_ranges(&temp, 1));
> +
> +		reclaimed_count += to_reclaim;
> +		page_index = 0;
> +	}
> +
> +out_unlock:
> +	hyp_spin_unlock(&host_buffers.lock);
> +
> +	if (ret)
> +		ffa_to_smccc_res(res, ret);
> +}
> +
>  static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
>  			       struct kvm_cpu_context *ctxt)
>  {
> @@ -1107,6 +1221,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
>  	case FFA_MEM_RECLAIM:
>  		do_ffa_mem_reclaim(&res, host_ctxt);
>  		goto out_handled;
> +	case FFA_FN64_MEM_RECLAIM2:
> +		do_ffa_mem_reclaim2(&res, host_ctxt);
> +		goto out_handled;
>  	case FFA_MEM_LEND:
>  	case FFA_FN64_MEM_LEND:
>  		do_ffa_mem_xfer(FFA_FN64_MEM_LEND, &res, host_ctxt);
> -- 
> 2.55.0.1082.g2b9226bbc0-goog
> 

-- 
Vincent

Re: [PATCH 1/2] firmware: arm_ffa: Add FFA_FN64_MEM_RECLAIM2 function ID

[Snehal Koukuntla]

On Mon, Sep 21, 2026 at 04:58:41PM +0000, sashiko-bot wrote:
> [Severity: Low]
> Does the missing 32-bit counterpart for FFA_FN64_MEM_RECLAIM2 break
> FFA_FN_NATIVE() compatibility on 32-bit architectures?
> 
> Every other FFA_FN64_ prefix in the header has a 32-bit counterpart. If
> FFA_FN_NATIVE(MEM_RECLAIM2) is ever used on a 32-bit build, it will evaluate
> to FFA_MEM_RECLAIM2 due to the architecture-conditional logic, which does
> not exist here, and would cause a compilation failure.
> 
> For 64-bit exclusive ABIs like FFA_MSG_SEND_DIRECT_REQ2, the convention
> is to omit the FN64_ prefix entirely.

Ack, I will rename this to FFA_MEM_RECLAIM2 in v2 to follow the existing
convention for 64-bit-only ABIs in arm_ffa.h.

Thanks,
Snehal

Re: [PATCH 2/2] KVM: arm64: Support FFA_FN64_MEM_RECLAIM2 in host handler

[Snehal Koukuntla]

Hi Vincent,

On Tue, Sep 22, 2026 at 10:07:27AM +0000, Vincent Donnefort wrote:
> > +	if (ffa_check_unused_args_sbz(ctxt, 6) || (flags & ~1ULL) || (x4 >> 32)) {
> 
> nit: (flags > 1) ?

Ack, will update in v2.

> > +	if (offset % desc_size != 0) {
> 
> nit: 
> 
> if (offset % desc_size) is enough

Ack.

> > +	if (offset >= (u64)req_desc_cnt * desc_size) {
> > +		ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > +		return;
> > +	}
> 
> Not sure I understand what Sashiko means here offset can not be bigger than the
> number of constituents we have...
> 
> > +
> > +	hyp_spin_lock(&host_buffers.lock);
> > +	if (!host_buffers.tx) {
> > +		ret = FFA_RET_INVALID_PARAMETERS;
> > +		goto out_unlock;
> > +	}
> > +
> > +	memcpy(hyp_buffers.tx, host_buffers.tx, (u64)req_desc_cnt * desc_size);
> 
> Either I or Sashiko is confused here. The invocation will not do more than
> req_desc_cnt will it?

Agreed. Per [S0039] and [S0047] in the spec, req_desc_cnt is the total
count of constituent descriptors in the TX buffer array starting at
offset 0, and offset indexes into that array so callers can advance
offset on subsequent invocations without repopulating the array.

> > +
> > +	range = (void *)hyp_buffers.tx + offset;
> > +	if (page_index >= range->pg_cnt) {
> > +		ret = FFA_RET_INVALID_PARAMETERS;
> > +		goto out_unlock;
> > +	}
> 
> Should we also verify total_pages here?

Good catch. I will add a check in v2 to verify that the sum of pg_cnt
across the constituent descriptors matches total_pages (without
overflowing) before forwarding the call.

Thanks,
Snehal

Re: [PATCH 1/2] firmware: arm_ffa: Add FFA_FN64_MEM_RECLAIM2 function ID

[Sudeep Holla]

On Mon, Sep 21, 2026 at 04:47:47PM +0000, Snehal Koukuntla wrote:
> FF-A v1.3 ALP5 (DEN0140 rev J) introduces the optional FFA_MEM_RECLAIM2
> (0xC4000091) ABI, which enables an Owner to reclaim exclusive access to
> a subset of pages of a memory region without requiring the Relayer to
> maintain intermediate transaction state.
> 
> Add the FFA_FN64_MEM_RECLAIM2 function ID definition to arm_ffa.h.
> 

Since the spec is still at ALPHA, I suggest to add RFC in the subject
if you post newer version so that it is *NOT* considered for merging
until spec reaches *BETA*.

-- 
Regards,
Sudeep

Re: [PATCH 1/2] firmware: arm_ffa: Add FFA_FN64_MEM_RECLAIM2 function ID

[Snehal Koukuntla]

Hi Sudeep,

On Tue, Sep 22, 2026 at 01:15:52PM +0100, Sudeep Holla wrote:
> On Mon, Sep 21, 2026 at 04:47:47PM +0000, Snehal Koukuntla wrote:
> > FF-A v1.3 ALP5 (DEN0140 rev J) introduces the optional FFA_MEM_RECLAIM2
> > (0xC4000091) ABI, which enables an Owner to reclaim exclusive access to
> > a subset of pages of a memory region without requiring the Relayer to
> > maintain intermediate transaction state.
> > 
> > Add the FFA_FN64_MEM_RECLAIM2 function ID definition to arm_ffa.h.
> > 
> 
> Since the spec is still at ALPHA, I suggest to add RFC in the subject
> if you post newer version so that it is *NOT* considered for merging
> until spec reaches *BETA*.

Makes sense, I will mark v2 with [RFC PATCH v2] in the subject.

Thanks,
Snehal