[PATCH] KVM: arm64: Allow smaller FF-A RX/TX buffers

[PATCH] KVM: arm64: Allow smaller FF-A RX/TX buffers

[Kim Mankyum via B4 Relay]

From: Kim Mankyum <mankyum.kim@samsung.com>

pKVM currently requires the host to map PAGE_SIZE worth of RX/TX
buffers, as do_ffa_rxtx_map() requires the FF-A page count to match
the capacity of the hypervisor RX/TX buffers.

This is unnecessarily restrictive when the kernel page size is larger
than the minimum RX/TX buffer size advertised by the SPMC. For
example, with a 16K kernel and an SPMC advertising a minimum RX/TX
buffer size of 4K, a host request with a page count of one is rejected
by pKVM.

hyp_ffa_post_init() already allows an SPMC whose minimum RX/TX buffer
size is smaller than PAGE_SIZE, and the page count supplied by the host
is forwarded unchanged when mapping the hypervisor buffers into the
SPMC.

Allow RX/TX buffers smaller than the capacity of the hypervisor buffers
while continuing to reject requests which exceed it.

Fixes: 9d0c6a9af9e3 ("KVM: arm64: Handle FFA_RXTX_MAP and FFA_RXTX_UNMAP calls from the host")
Signed-off-by: Kim Mankyum <mankyum.kim@samsung.com>
---
 arch/arm64/kvm/hyp/nvhe/ffa.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index a327c2bbb6b6..594d1112b5f9 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -239,7 +239,8 @@ static void do_ffa_rxtx_map(struct arm_smccc_1_2_regs *res,
 	int ret = 0;
 	void *rx_virt, *tx_virt;
 
-	if (npages != (KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) / FFA_PAGE_SIZE) {
+	if (!npages ||
+	    npages > (KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) / FFA_PAGE_SIZE) {
 		ret = FFA_RET_INVALID_PARAMETERS;
 		goto out;
 	}

---
base-commit: cb8a75eec0877810b50aa1c5a833f929525cd2ee
change-id: 20260820-master-572418a358ab

Best regards,
--  
Kim Mankyum <mankyum.kim@samsung.com>

Re: [PATCH] KVM: arm64: Allow smaller FF-A RX/TX buffers

[Marc Zyngier]

On Thu, 20 Aug 2026 06:42:31 +0100,
Kim Mankyum via B4 Relay <devnull+mankyum.kim.samsung.com@kernel.org> wrote:
> 
> From: Kim Mankyum <mankyum.kim@samsung.com>
> 
> pKVM currently requires the host to map PAGE_SIZE worth of RX/TX
> buffers, as do_ffa_rxtx_map() requires the FF-A page count to match
> the capacity of the hypervisor RX/TX buffers.
> 
> This is unnecessarily restrictive when the kernel page size is larger
> than the minimum RX/TX buffer size advertised by the SPMC. For
> example, with a 16K kernel and an SPMC advertising a minimum RX/TX
> buffer size of 4K, a host request with a page count of one is rejected
> by pKVM.
> 
> hyp_ffa_post_init() already allows an SPMC whose minimum RX/TX buffer
> size is smaller than PAGE_SIZE, and the page count supplied by the host
> is forwarded unchanged when mapping the hypervisor buffers into the
> SPMC.
> 
> Allow RX/TX buffers smaller than the capacity of the hypervisor buffers
> while continuing to reject requests which exceed it.

You don't explain why this is safe.

Are you guaranteed that the physical page stays accessible to the
host?

What happens if another range in the same physical page gets shared
again? Best case, this will fail, but why is that an acceptable
behaviour?

You need to provide answers to these questions before we can consider
this change.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH] KVM: arm64: Allow smaller FF-A RX/TX buffers

[Sebastian Ene]

On Thu, Aug 20, 2026 at 02:42:31PM +0900, Kim Mankyum wrote:

Hello Kim,

> pKVM currently requires the host to map PAGE_SIZE worth of RX/TX
> buffers, as do_ffa_rxtx_map() requires the FF-A page count to match
> the capacity of the hypervisor RX/TX buffers.
> 
> This is unnecessarily restrictive when the kernel page size is larger
> than the minimum RX/TX buffer size advertised by the SPMC. For
> example, with a 16K kernel and an SPMC advertising a minimum RX/TX
> buffer size of 4K, a host request with a page count of one is rejected
> by pKVM.
> 

That is because we should trap and report the minimum number of pages
from pKVM and not from SPMC. The host doesn't end up mapping directly in
the SPMC.

Something like this should do the trick:

```
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 48cf502ce1e7..95156d409f79 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -1355,7 +1355,7 @@ static bool do_ffa_features(struct arm_smccc_1_2_regs *res,
                            struct kvm_cpu_context *ctxt)
 {
        DECLARE_REG(u32, id, ctxt, 1);
-       u64 prop = 0;
+       u64 prop = 0, buff_sz;
        int ret = 0;
 
        if (!ffa_call_supported(id)) {
@@ -1364,6 +1364,18 @@ static bool do_ffa_features(struct arm_smccc_1_2_regs *res,
        }
 
        switch (id) {
+       case FFA_RXTX_MAP:
+       case FFA_FN64_RXTX_MAP:
+               buff_sz = KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE;
+               if (buff_sz == SZ_4K)
+                       prop = FFA_FEAT_RXTX_MIN_SZ_4K;
+               else if (buff_sz == SZ_64K)
+                       prop = FFA_FEAT_RXTX_MIN_SZ_64K;
+               else if (buff_sz == SZ_16K)
+                       prop = FFA_FEAT_RXTX_MIN_SZ_16K;
+               else
+                       ret = FFA_RET_NOT_SUPPORTED;
+               goto out_handled;
        case FFA_MEM_SHARE:
        case FFA_FN64_MEM_SHARE:
        case FFA_MEM_LEND:
```

> hyp_ffa_post_init() already allows an SPMC whose minimum RX/TX buffer
> size is smaller than PAGE_SIZE, and the page count supplied by the host
> is forwarded unchanged when mapping the hypervisor buffers into the
> SPMC.
> 
> Allow RX/TX buffers smaller than the capacity of the hypervisor buffers
> while continuing to reject requests which exceed it.
> 

I don't think you should change that, it will probably brake things because the hyp knows that
it is using KVM_FFA_MBOX_NR_PAGES but you only mapped npages in SPMC. 

I have some android patch where I am also trying to remove the limitation that the hypervisor has
only one page per mailbox buffer (set in stone that KVM_FFA_MBOX_NR_PAGES is 1) :
https://android-review.googlesource.com/c/kernel/common/+/4238522

This should probably put you in a better position for a patch ?


> Fixes: 9d0c6a9af9e3 ("KVM: arm64: Handle FFA_RXTX_MAP and FFA_RXTX_UNMAP calls from the host")
> Signed-off-by: Kim Mankyum <mankyum.kim@samsung.com>
> ---
>  arch/arm64/kvm/hyp/nvhe/ffa.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index a327c2bbb6b6..594d1112b5f9 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -239,7 +239,8 @@ static void do_ffa_rxtx_map(struct arm_smccc_1_2_regs *res,
>  	int ret = 0;
>  	void *rx_virt, *tx_virt;
>  
> -	if (npages != (KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) / FFA_PAGE_SIZE) {
> +	if (!npages ||
> +	    npages > (KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) / FFA_PAGE_SIZE) {
>  		ret = FFA_RET_INVALID_PARAMETERS;
>  		goto out;
>  	}
> 
> ---
> base-commit: cb8a75eec0877810b50aa1c5a833f929525cd2ee
> change-id: 20260820-master-572418a358ab
> 
> Best regards,
> --  
> Kim Mankyum <mankyum.kim@samsung.com>
>

Thanks,
Sebastian 

Re: Re: [PATCH] KVM: arm64: Allow smaller FF-A RX/TX buffers

[Sebastian Ene]

>On Mon, Aug 24, 2026 at 09:53:45AM +0900, Mankyum Kim wrote:

Hello,

>Hi Sebastian,
>
>
>
>Thanks for the feedback. I took another look at the SPMC capability
>reporting and found an important detail that I missed in v1.
>
>
>
>With FF-A, the SPMC in this configuration advertises both the minimum
>and maximum RX/TX buffer sizes as 4K. `hyp_ffa_post_init()` currently
>only considers the minimum size and ignores the maximum.
>
(making it readable as the reply was sent in html format)

The max size discovery has been added from FF-A 1.2. Old SPMCs with <
1.2 will not have it.

>
>
>I agree that the host-facing FFA_FEATURES should report pKVM's RX/TX
>requirement, as you suggested. That would keep the host/pKVM mapping at
>the host page granularity and also avoid the partial-page sharing issue
>Marc pointed out.
>
>
>
>However, with a 16K host/pKVM, the host would then request:
>
>
>
>```
>
>FFA_RXTX_MAP(..., page-count=4)
>
>```
>
>
>
>and the current `ffa_map_hyp_buffers(npages)` would forward the same
>page count to the SPMC. This SPMC advertises a maximum RX/TX buffer size
>of 4K, so the 16K mapping is rejected.
>

Right, I see what you mean. In this case we would have to :

- keep track in a variable for the size of the hyp mailbox buffer
  (pkvm_ffa_bufsz) let's say

- make hyp_ffa_post_init aware of the max RX/TX discovered size if we
  are running with FF-A >= 1.2

  if max_rxtx_sz < PAGE_SIZE * KVM_FFA_MBOX_NR_PAGES:
  	pkvm_ffa_bufsz = max_rxtx_sz;

- if we are running with FF-A < 1.2:
	pkvm_ffa_bufsz = min_rxtx_sz

- update the code for the host-facing FFA_FEATURES to report
  pkvm_ffa_bufsz when queried from host and make sure we use that
  instead of the paths that use KVM_FFA_MBOX_NR_PAGES

>
>
>It therefore looks like supporting this configuration would require
>separating the host-facing RX/TX size from the SPMC-facing RX/TX size. I
>also noticed that several paths currently use `KVM_FFA_MBOX_NR_PAGES *
>PAGE_SIZE` as the capacity of the hyp buffers, so simply mapping the hyp
>buffers with a page count of one doesn't seem sufficient.
>
>
>
>I'll drop the approach taken in v1.
>
>
>
>Does this match your understanding? In particular, do you think your
>configurable mailbox work could be extended to support different
>host-facing and SPMC-facing RX/TX sizes, or would you handle that
>separately?
>
>
>
>Thanks,
>
>Mankyum

Thanks,
Sebastian