Re: [PATCH] arm64: swiotlb: Keep the default size for protected guests

Will Deacon [off-list ref] writes:

On Fri, Aug 07, 2026 at 06:33:14PM +0530, Aneesh Kumar K.V wrote:

quoted

Will Deacon [off-list ref] writes:

quoted

On Fri, Aug 07, 2026 at 02:56:12PM +0530, Aneesh Kumar K.V (Arm) wrote:

quoted

Realm guests and protected KVM guests may require swiotlb for device DMA
even when all system RAM is addressable by the DMA zones.

Do not reduce the SWIOTLB buffer to the kmalloc-bouncing size for these
guests, as the reduced number of slots can be exhausted during CCA guest
operation.

Fixes: 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED")
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
 arch/arm64/mm/init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e308a7cabd12..24caaf10e755 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c

@@ -339,7 +339,8 @@ void __init arch_mm_preinit(void)
 {
 	unsigned int flags = SWIOTLB_VERBOSE;
 
-	if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
+	if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {

Protected guests under pKVM rely on restricted DMA, so won't this just
waste memory for them?

commit 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED"),
which this patch fixes, has

--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c

@@ -339,9 +339,7 @@ void __init arch_mm_preinit(void)
 {
        unsigned int flags = SWIOTLB_VERBOSE;
 
-       if (is_realm_world() || is_protected_kvm_guest()) {
-               flags |= SWIOTLB_FORCE;
-       } else if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
+       if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
                /*
                 * If no bouncing needed for ZONE_DMA, reduce the swiotlb
                 * buffer for kmalloc() bouncing to 1MB per 1GB of RAM.

The is_protected_kvm_guest() part was added by the 
commit e62decaf98e7 ("arm64/coco: Add pKVM as a CC platform")

@@ -337,7 +339,7 @@ void __init arch_mm_preinit(void)
 {
        unsigned int flags = SWIOTLB_VERBOSE;
 
-       if (is_realm_world()) {
+       if (is_realm_world() || is_protected_kvm_guest()) {
                flags |= SWIOTLB_FORCE;
        } else if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
                /*

@@ -412,6 +414,17 @@ void dump_mem_limit(void)
        }
 }

I was under the impression that there is a possibility of using swiotlb
instead of restricted-dma-pool with pKVM.

Yes, that patch enables swiotlb as a possibility for protected guests
but with your patch we avoid shrinking the swiotlb buffer even when
restricted dma pools are being used and that's a waste of memory.

The patch restores the behavior to what it was before that commit. That
is, for both CCA and pKVM, we don't do the max_pfn check, and hence the
swiotlb is never resized.

quoted

If that is not the case, then we could change:

!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&

to

!is_realm_world() &&

Perhaps, or you could just pass the swiotlb= option if the defaults don't
work for you. Can you give more details about the slots exhaustion you're
seeing under CCA?

That is definitely possible. However, on arm64, the current code further
reduces the default swiotlb size when max_pfn < arm64_dma_phys_limit.
That reduction is only correct when swiotlb is being used as a bounce
buffer because of arm64_dma_phys_limit.

With CCA, that is not the case. We use swiotlb to bounce DMA for
untrusted devices. Therefore, reducing the default swiotlb size based on
max_pfn is not correct for CCA configurations.

This change in behavior is also a regression for CCA. CCA configurations
that booted successfully before now gives the error below.


[   39.848004] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 256 (slots), used 159 (slots)
[   40.002654] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 256 (slots), used 159 (slots)
[   40.165933] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 256 (slots), used 159 (slots)
[   40.325465] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 512 (slots), used 415 (slots)
[   40.485932] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 204800 bytes), total 768 (slots), used 671 (slots)
[   42.485337] EXT4-fs (vda): re-mounted 6870157e-2795-475e-aad6-3a05725fb7cf.
[   43.799800] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 1280 (slots), used 1153 (slots)
[   44.016682] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 1280 (slots), used 1153 (slots)
[   44.226566] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 1536 (slots), used 1409 (slots)
[   44.437194] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 1792 (slots), used 1665 (slots)

-aneesh