Re: [PATCH v3 08/10] KVM: arm64: Handle FFA_MEM_LEND calls from the host

Re: [PATCH v3 08/10] KVM: arm64: Handle FFA_MEM_LEND calls from the host

[Will Deacon]

On Sat, Jul 12, 2025 at 10:36:24PM +0900, DaeRo Lee wrote:
> > Handle FFA_MEM_LEND calls from the host by treating them identically to
> > FFA_MEM_SHARE calls for the purposes of the host stage-2 page-table, but
> > forwarding on the original request to EL3.
> 
> I have a question about your patch.
> Does treating FFA_MEM_LEND as identical to FFA_MEM_SHARE imply that
> the host can still access the memory even after it has been lent?

Only if your TZ implementation is broken and relies on the NS hypervisor
for isolation.

Will

Re: [PATCH v3 08/10] KVM: arm64: Handle FFA_MEM_LEND calls from the host

[DaeRo Lee]

> > > Handle FFA_MEM_LEND calls from the host by treating them identically to
> > > FFA_MEM_SHARE calls for the purposes of the host stage-2 page-table, but
> > > forwarding on the original request to EL3.
> > 
> > I have a question about your patch.
> > Does treating FFA_MEM_LEND as identical to FFA_MEM_SHARE imply that
> > the host can still access the memory even after it has been lent?
>
> Only if your TZ implementation is broken and relies on the NS hypervisor
> for isolation.

I believe pKVM is managing stage 2 isolation between Host and Non-secure Guest
VMs or between Non-secure Guest VMs

<Quote DEN0140_FF-A_Memory Management Protocol>
2.2.1.2 Relayer responsibilities
10. Unmap the memory region from the translation regime of the Lender, if
managed by the Relayer as specified in 1.2 Address translation regimes. This 
must be done only if the memory region is in the Owner-EA state. This includes
removing access to the memory region from any DMA capable devices assigned to 
the Lender.

From the content, it seems that when performing a Lend operation, it's
necessary to perform a Stage 2 unmap of the host memory area. Am I understanding
this correctly?

Re: [PATCH v3 08/10] KVM: arm64: Handle FFA_MEM_LEND calls from the host

[Will Deacon]

On Sun, Jul 13, 2025 at 11:59:57PM +0900, DaeRo Lee wrote:
> > > > Handle FFA_MEM_LEND calls from the host by treating them identically to
> > > > FFA_MEM_SHARE calls for the purposes of the host stage-2 page-table, but
> > > > forwarding on the original request to EL3.
> > > 
> > > I have a question about your patch.
> > > Does treating FFA_MEM_LEND as identical to FFA_MEM_SHARE imply that
> > > the host can still access the memory even after it has been lent?
> >
> > Only if your TZ implementation is broken and relies on the NS hypervisor
> > for isolation.
> 
> I believe pKVM is managing stage 2 isolation between Host and Non-secure Guest
> VMs or between Non-secure Guest VMs
> 
> <Quote DEN0140_FF-A_Memory Management Protocol>
> 2.2.1.2 Relayer responsibilities
> 10. Unmap the memory region from the translation regime of the Lender, if
> managed by the Relayer as specified in 1.2 Address translation regimes. This 
> must be done only if the memory region is in the Owner-EA state. This includes
> removing access to the memory region from any DMA capable devices assigned to 
> the Lender.
> 
> From the content, it seems that when performing a Lend operation, it's
> necessary to perform a Stage 2 unmap of the host memory area. Am I understanding
> this correctly?

No.

pKVM doesn't use FF-A to manage host/guest page ownership.

FF-A is only used for memory management with the Secure world, in which
case a LEND transaction will mean that the Secure world must prevent
Non-Secure access to the memory itself and not rely on pKVM to unmap
at stage-2.

Will

Re: [PATCH v3 08/10] KVM: arm64: Handle FFA_MEM_LEND calls from the host

[DaeRo Lee]

Is it pKVM's policy to not manage Non-secure memory using FF-A, while the FF-A
specification supports memory management between Host/Guest within Non-secure
hypervisors?

Then, how does someone lend memory to a Guest from the Host/Guest via FF-A? Can
pKVM prevent this? Or should Host/Guest developers use it with caution?

Re: [PATCH v3 08/10] KVM: arm64: Handle FFA_MEM_LEND calls from the host

[Will Deacon]

On Mon, Jul 14, 2025 at 11:14:00AM +0900, DaeRo Lee wrote:
> Is it pKVM's policy to not manage Non-secure memory using FF-A, while the FF-A
> specification supports memory management between Host/Guest within Non-secure
> hypervisors?
> 
> Then, how does someone lend memory to a Guest from the Host/Guest via FF-A? Can
> pKVM prevent this? Or should Host/Guest developers use it with caution?


Perhaps you could read the code and find out.

Will

Re: [PATCH v3 08/10] KVM: arm64: Handle FFA_MEM_LEND calls from the host

[DaeRo Lee]

Is it pKVM's policy to not manage Non-secure memory using FF-A, while the FF-A
specification supports memory management between Host/Guest within Non-secure
hypervisors?

Then, how does someone lend memory to a Guest from the Host/Guest via FF-A? Can
pKVM prevent this? Or should Host/Guest developers use it with caution?

[PATCH v3 00/10] KVM: arm64: FF-A proxy for pKVM

[Will Deacon]

Hi all,

This is version three of the pKVM FF-A proxy series previously posted
here:

v1: https://lore.kernel.org/r/20221116170335.2341003-1-qperret@google.com
v2: https://lore.kernel.org/r/20230419122051.1341-1-will@kernel.org

Changes since v2 include:

  * Rename 'spmd_' functions per suggestion from Oliver
  * Add some more comments
  * Rebase onto 6.4-rc3

Cheers,

Will

Cc: Quentin Perret <qperret@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: James Morse <james.morse@arm.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Sebastian Ene <sebastianene@google.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: kvmarm@lists.linux.dev
Cc: kernel-team@android.com

--->8

Fuad Tabba (1):
  KVM: arm64: Handle FFA_FEATURES call from the host

Quentin Perret (1):
  KVM: arm64: pkvm: Add support for fragmented FF-A descriptors

Will Deacon (8):
  KVM: arm64: Block unsafe FF-A calls from the host
  KVM: arm64: Probe FF-A version and host/hyp partition ID during init
  KVM: arm64: Allocate pages for hypervisor FF-A mailboxes
  KVM: arm64: Handle FFA_RXTX_MAP and FFA_RXTX_UNMAP calls from the host
  KVM: arm64: Add FF-A helpers to share/unshare memory with secure world
  KVM: arm64: Handle FFA_MEM_SHARE calls from the host
  KVM: arm64: Handle FFA_MEM_RECLAIM calls from the host
  KVM: arm64: Handle FFA_MEM_LEND calls from the host

 arch/arm64/include/asm/kvm_host.h             |   1 +
 arch/arm64/include/asm/kvm_pkvm.h             |  21 +
 arch/arm64/kvm/arm.c                          |   1 +
 arch/arm64/kvm/hyp/include/nvhe/ffa.h         |  17 +
 arch/arm64/kvm/hyp/include/nvhe/mem_protect.h |   3 +
 arch/arm64/kvm/hyp/nvhe/Makefile              |   2 +-
 arch/arm64/kvm/hyp/nvhe/ffa.c                 | 762 ++++++++++++++++++
 arch/arm64/kvm/hyp/nvhe/hyp-main.c            |   3 +
 arch/arm64/kvm/hyp/nvhe/mem_protect.c         |  68 ++
 arch/arm64/kvm/hyp/nvhe/setup.c               |  11 +
 arch/arm64/kvm/pkvm.c                         |   1 +
 include/linux/arm_ffa.h                       |   8 +
 12 files changed, 897 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kvm/hyp/include/nvhe/ffa.h
 create mode 100644 arch/arm64/kvm/hyp/nvhe/ffa.c

-- 
2.40.1.698.g37aff9b760-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 08/10] KVM: arm64: Handle FFA_MEM_LEND calls from the host

[Will Deacon]

Handle FFA_MEM_LEND calls from the host by treating them identically to
FFA_MEM_SHARE calls for the purposes of the host stage-2 page-table, but
forwarding on the original request to EL3.

Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/kvm/hyp/nvhe/ffa.c | 22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 550936f4b5da..d90ab1c9ec72 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -116,10 +116,10 @@ static int ffa_unmap_hyp_buffers(void)
 	return res.a0 == FFA_SUCCESS ? FFA_RET_SUCCESS : res.a2;
 }
 
-static void ffa_mem_share(struct arm_smccc_res *res, u32 len, u32 fraglen)
+static void ffa_mem_xfer(struct arm_smccc_res *res, u64 func_id, u32 len,
+			  u32 fraglen)
 {
-	arm_smccc_1_1_smc(FFA_FN64_MEM_SHARE,
-			  len, fraglen,
+	arm_smccc_1_1_smc(func_id, len, fraglen,
 			  0, 0, 0, 0, 0,
 			  res);
 }
@@ -321,8 +321,9 @@ static int ffa_host_unshare_ranges(struct ffa_mem_region_addr_range *ranges,
 	return ret;
 }
 
-static void do_ffa_mem_share(struct arm_smccc_res *res,
-			     struct kvm_cpu_context *ctxt)
+static __always_inline void do_ffa_mem_xfer(const u64 func_id,
+					    struct arm_smccc_res *res,
+					    struct kvm_cpu_context *ctxt)
 {
 	DECLARE_REG(u32, len, ctxt, 1);
 	DECLARE_REG(u32, fraglen, ctxt, 2);
@@ -333,6 +334,9 @@ static void do_ffa_mem_share(struct arm_smccc_res *res,
 	int ret = 0;
 	u32 offset;
 
+	BUILD_BUG_ON(func_id != FFA_FN64_MEM_SHARE &&
+		     func_id != FFA_FN64_MEM_LEND);
+
 	if (addr_mbz || npages_mbz || fraglen > len ||
 	    fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
 		ret = FFA_RET_INVALID_PARAMETERS;
@@ -382,7 +386,7 @@ static void do_ffa_mem_share(struct arm_smccc_res *res,
 	if (ret)
 		goto out_unlock;
 
-	ffa_mem_share(res, len, fraglen);
+	ffa_mem_xfer(res, func_id, len, fraglen);
 	if (res->a0 != FFA_SUCCESS) {
 		WARN_ON(ffa_host_unshare_ranges(reg->constituents,
 						reg->addr_range_cnt));
@@ -519,11 +523,15 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt)
 		goto out_handled;
 	case FFA_MEM_SHARE:
 	case FFA_FN64_MEM_SHARE:
-		do_ffa_mem_share(&res, host_ctxt);
+		do_ffa_mem_xfer(FFA_FN64_MEM_SHARE, &res, host_ctxt);
 		goto out_handled;
 	case FFA_MEM_RECLAIM:
 		do_ffa_mem_reclaim(&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);
+		goto out_handled;
 	}
 
 	if (ffa_call_supported(func_id))
-- 
2.40.1.698.g37aff9b760-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel