dma: swiotlb: Centralize default pool policy and sizing

Memory-encrypted guests use shared or unencrypted memory for DMA and may route all DMA through SWIOTLB. The default pool can therefore be too small for I/O-intensive workloads.

Move the existing x86 guest-sizing policy into the SWIOTLB core. For SWIOTLB_POOL_CC_GUEST, size the pool to 6% of guest memory, clamped between the normal default and 1 GiB. Preserve an explicit swiotlb= size.

Host memory encryption still selects a normal-sized shared pool and does not use the guest-sizing policy.

A restricted DMA pool already provides shared bounce buffers for its devices. Record its presence during reserved-memory initialization and do not select the confidential-guest default-pool policy solely because guest memory encryption is active.

Reviewed-by Catalin Marinas <[email protected]>

Cc Dave Hansen <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc [email protected]

Cc "H. Peter Anvin" <[email protected]>

Cc Marek Szyprowski <[email protected]>

Cc Robin Murphy <[email protected]>

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

---
 arch/x86/mm/mem_encrypt.c | 24 ------------------------
 kernel/dma/swiotlb.c      | 27 +++++++++++++++++++++++++--
 2 files changed, 25 insertions(+), 26 deletions(-)

arch/x86/mm/mem_encrypt.c +0 -24

index 95bae74fdab2..912f22ca838f 100644
@@ -101,9 +101,6 @@ void __init mem_encrypt_init(void)
 
 void __init mem_encrypt_setup_arch(void)
 {
-	phys_addr_t total_mem = memblock_phys_mem_size();
-	unsigned long size;
-
 	/*
 	 * Do RMP table fixups after the e820 tables have been setup by
 	 * e820__memory_setup().

@@ -114,27 +111,6 @@ void __init mem_encrypt_setup_arch(void)
 	if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
 		return;
 
-	/*
-	 * For SEV and TDX, all DMA has to occur via shared/unencrypted pages.
-	 * Kernel uses SWIOTLB to make this happen without changing device
-	 * drivers. However, depending on the workload being run, the
-	 * default 64MB of SWIOTLB may not be enough and SWIOTLB may
-	 * run out of buffers for DMA, resulting in I/O errors and/or
-	 * performance degradation especially with high I/O workloads.
-	 *
-	 * Adjust the default size of SWIOTLB using a percentage of guest
-	 * memory for SWIOTLB buffers. Also, as the SWIOTLB bounce buffer
-	 * memory is allocated from low memory, ensure that the adjusted size
-	 * is within the limits of low available memory.
-	 *
-	 * The percentage of guest memory used here for SWIOTLB buffers
-	 * is more of an approximation of the static adjustment which
-	 * 64MB for <1G, and ~128M to 256M for 1G-to-4G, i.e., the 6%
-	 */
-	size = total_mem * 6 / 100;
-	size = clamp_val(size, IO_TLB_DEFAULT_SIZE, SZ_1G);
-	swiotlb_adjust_size(size);
-
 	/* Set restricted memory access for virtio. */
 	virtio_set_mem_acc_cb(virtio_require_restricted_mem_acc);
 }

kernel/dma/swiotlb.c +21 -1

index 75ee63cd354e..e626cca63ad1 100644
@@ -33,6 +33,7 @@
 #include <linux/kmsan-checks.h>
 #include <linux/iommu-helper.h>
 #include <linux/init.h>
+#include <linux/math64.h>
 #include <linux/memblock.h>
 #include <linux/mm.h>
 #include <linux/pfn.h>

@@ -80,6 +81,7 @@ struct io_tlb_slot {
 
 static bool swiotlb_force_bounce;
 static bool swiotlb_force_disable;
+static bool restricted_dma_pool_present __initdata;
 
 enum swiotlb_pool_policy {
 	SWIOTLB_POOL_NONE,

@@ -478,7 +480,25 @@ swiotlb_adjust_pool_size(enum swiotlb_pool_policy policy)
 		size = min(swiotlb_default_pool_size(), size);
 		break;
 	case SWIOTLB_POOL_CC_GUEST:
-		return;
+		/*
+		 * For SEV and TDX and CCA, all DMA has to occur via
+		 * shared/unencrypted pages. Kernel uses SWIOTLB to make this
+		 * happen without changing device drivers. However, depending on
+		 * the workload being run, the default 64MB of SWIOTLB may not be
+		 * enough and SWIOTLB may run out of buffers for DMA, resulting in
+		 * I/O errors and/or performance degradation especially with high
+		 * I/O workloads.
+		 *
+		 * Adjust the default size of SWIOTLB using a percentage of guest
+		 * memory for SWIOTLB buffers.
+		 *
+		 * The percentage of guest memory used here for SWIOTLB buffers is
+		 * more of an approximation of the static adjustment which 64MB for
+		 * <1G, and ~128M to 256M for 1G-to-4G, i.e., the 6%
+		 */
+		size = div_u64((u64)memblock_phys_mem_size() * 6, 100);
+		size = clamp_val(size, IO_TLB_DEFAULT_SIZE, SZ_1G);
+		break;
 	case SWIOTLB_POOL_NONE:
 		WARN(true, "Cannot adjust SWIOTLB size without a pool\n");
 		return;

Quoted 4 lines · Aneesh Kumar K.V (Arm)

kernel/dma/swiotlb.c +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

kernel/dma/swiotlb.c swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

kernel/dma/swiotlb.c +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 5 lines · Will Deacon

Quoted 4 lines · Aneesh Kumar K.V (Arm)

kernel/dma/swiotlb.c +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

Quoted 8 lines

kernel/dma/swiotlb.c swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

kernel/dma/swiotlb.c +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Another option could be the arch code passing another flag that it doesn't want an encrypted pool (e.g. when running in a pKVM guest) but I don't particularly this either. The arch code doesn't know whether there's an alternative pool.

That said, such heuristics should have been a separate patch to make it easier to review/drop.

Quoted 14 lines · Catalin Marinas

Quoted 13 lines · Will Deacon

kernel/dma/swiotlb.c swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 8 lines · Aneesh Kumar K.V (Arm)

kernel/dma/swiotlb.c +2 -1

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 
-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 2 lines

That said, such heuristics should have been a separate patch to make it easier to review/drop.

I think the only right way to get a semi-accurate heuristic is to take into account the set of dma-capable devices that will use the swiotlb pool, but that's fiddly and should probably be tackled as a separate series. Maybe a simpler hack in that direction would be to take the SWIOTLB_POOL_CC_GUEST if _any_ device is going to use swiotlb? You'll run into the usual problem of not being able to tell if a device is DMA-capable or not, but you could probably look for a global restricted DMA pool and, if that doesn't exist, check for per-device restricted pools on dma-coherent devices (since restricted DMA isn't supported by ACPI) as a reasonable approximation.

Quoted 15 lines · Catalin Marinas

Quoted 5 lines · Will Deacon

Quoted 4 lines · Aneesh Kumar K.V (Arm)

kernel/dma/swiotlb.c +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

Quoted 8 lines

kernel/dma/swiotlb.c swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

kernel/dma/swiotlb.c +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 4 lines

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Hrm, that does mean that reverting just this part will regress pVMs because they'll suddenly be allocating a tonne more memory for an entirely unused swiotlb buffer. So I think I'd prefer to drop the entire series until this has been worked out properly.

Quoted 4 lines

Another option could be the arch code passing another flag that it doesn't want an encrypted pool (e.g. when running in a pKVM guest) but I don't particularly this either. The arch code doesn't know whether there's an alternative pool.

At that point, the default size may as well be driven by the drivers/virt/coco driver.

Quoted 2 lines

That said, such heuristics should have been a separate patch to make it easier to review/drop.

I think the only right way to get a semi-accurate heuristic is to take into account the set of dma-capable devices that will use the swiotlb pool, but that's fiddly and should probably be tackled as a separate series. Maybe a simpler hack in that direction would be to take the SWIOTLB_POOL_CC_GUEST if _any_ device is going to use swiotlb? You'll run into the usual problem of not being able to tell if a device is DMA-capable or not, but you could probably look for a global restricted DMA pool and, if that doesn't exist, check for per-device restricted pools on dma-coherent devices (since restricted DMA isn't supported by ACPI) as a reasonable approximation.

Quoted 37 lines · Will Deacon

Quoted 15 lines · Catalin Marinas

Quoted 5 lines · Will Deacon

Quoted 4 lines · Aneesh Kumar K.V (Arm)

kernel/dma/swiotlb.c +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

Quoted 8 lines

kernel/dma/swiotlb.c swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

kernel/dma/swiotlb.c +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 4 lines

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Hrm, that does mean that reverting just this part will regress pVMs because they'll suddenly be allocating a tonne more memory for an entirely unused swiotlb buffer. So I think I'd prefer to drop the entire series until this has been worked out properly.

Quoted 4 lines

Another option could be the arch code passing another flag that it doesn't want an encrypted pool (e.g. when running in a pKVM guest) but I don't particularly this either. The arch code doesn't know whether there's an alternative pool.

At that point, the default size may as well be driven by the drivers/virt/coco driver.

Quoted 2 lines

That said, such heuristics should have been a separate patch to make it easier to review/drop.

Quoted 10 lines

I think the only right way to get a semi-accurate heuristic is to take into account the set of dma-capable devices that will use the swiotlb pool, but that's fiddly and should probably be tackled as a separate series. Maybe a simpler hack in that direction would be to take the SWIOTLB_POOL_CC_GUEST if _any_ device is going to use swiotlb? You'll run into the usual problem of not being able to tell if a device is DMA-capable or not, but you could probably look for a global restricted DMA pool and, if that doesn't exist, check for per-device restricted pools on dma-coherent devices (since restricted DMA isn't supported by ACPI) as a reasonable approximation.

So, something like this?

	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
	    swiotlb_cc_guest_needs_default_pool())
		return SWIOTLB_POOL_CC_GUEST;

Quoted 49 lines · Aneesh Kumar K.V

Quoted 37 lines · Will Deacon

Quoted 15 lines · Catalin Marinas

Quoted 5 lines · Will Deacon

Quoted 4 lines · Aneesh Kumar K.V (Arm)

kernel/dma/swiotlb.c +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

Quoted 8 lines

kernel/dma/swiotlb.c swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

kernel/dma/swiotlb.c +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 4 lines

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Hrm, that does mean that reverting just this part will regress pVMs because they'll suddenly be allocating a tonne more memory for an entirely unused swiotlb buffer. So I think I'd prefer to drop the entire series until this has been worked out properly.

Quoted 4 lines

Another option could be the arch code passing another flag that it doesn't want an encrypted pool (e.g. when running in a pKVM guest) but I don't particularly this either. The arch code doesn't know whether there's an alternative pool.

At that point, the default size may as well be driven by the drivers/virt/coco driver.

Quoted 2 lines

That said, such heuristics should have been a separate patch to make it easier to review/drop.

Quoted 10 lines

I think the only right way to get a semi-accurate heuristic is to take into account the set of dma-capable devices that will use the swiotlb pool, but that's fiddly and should probably be tackled as a separate series. Maybe a simpler hack in that direction would be to take the SWIOTLB_POOL_CC_GUEST if _any_ device is going to use swiotlb? You'll run into the usual problem of not being able to tell if a device is DMA-capable or not, but you could probably look for a global restricted DMA pool and, if that doesn't exist, check for per-device restricted pools on dma-coherent devices (since restricted DMA isn't supported by ACPI) as a reasonable approximation.

Quoted 6 lines

So, something like this?

	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
	    swiotlb_cc_guest_needs_default_pool())
		return SWIOTLB_POOL_CC_GUEST;

Detecting a DMA-capable device is not straightforward, and if we get it wrong, we will enable SWIOTLB_POOL_CC_GUEST unnecessarily. Would the code below be a reasonable approximation of what you suggested?

Another option would be to make swiotlb_cc_guest_needs_default_pool() a weak function that architectures can override. arm64 pKVM could then use a different scheme (for this patch series default to false). Would that be preferable?

Quoted 57 lines · Aneesh Kumar K.V

Quoted 49 lines · Aneesh Kumar K.V

Quoted 37 lines · Will Deacon

Quoted 15 lines · Catalin Marinas

Quoted 5 lines · Will Deacon

Quoted 4 lines · Aneesh Kumar K.V (Arm)

(quoted diff) +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

Quoted 8 lines

Review swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

(quoted diff) +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 4 lines

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Hrm, that does mean that reverting just this part will regress pVMs because they'll suddenly be allocating a tonne more memory for an entirely unused swiotlb buffer. So I think I'd prefer to drop the entire series until this has been worked out properly.

Quoted 4 lines

Another option could be the arch code passing another flag that it doesn't want an encrypted pool (e.g. when running in a pKVM guest) but I don't particularly this either. The arch code doesn't know whether there's an alternative pool.

At that point, the default size may as well be driven by the drivers/virt/coco driver.

Quoted 2 lines

That said, such heuristics should have been a separate patch to make it easier to review/drop.

Quoted 10 lines

I think the only right way to get a semi-accurate heuristic is to take into account the set of dma-capable devices that will use the swiotlb pool, but that's fiddly and should probably be tackled as a separate series. Maybe a simpler hack in that direction would be to take the SWIOTLB_POOL_CC_GUEST if _any_ device is going to use swiotlb? You'll run into the usual problem of not being able to tell if a device is DMA-capable or not, but you could probably look for a global restricted DMA pool and, if that doesn't exist, check for per-device restricted pools on dma-coherent devices (since restricted DMA isn't supported by ACPI) as a reasonable approximation.

Quoted 6 lines

So, something like this?

	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
	    swiotlb_cc_guest_needs_default_pool())
		return SWIOTLB_POOL_CC_GUEST;

Quoted 8 lines

Detecting a DMA-capable device is not straightforward, and if we get it wrong, we will enable SWIOTLB_POOL_CC_GUEST unnecessarily. Would the code below be a reasonable approximation of what you suggested?

Another option would be to make swiotlb_cc_guest_needs_default_pool() a weak function that architectures can override. arm64 pKVM could then use a different scheme (for this patch series default to false). Would that be preferable?

Even the rmem check for each device is still a hack that may bite us in the future (private devices for example would not need swiotlb). I'm thinking more and more of leaving the sizing an arch-specific decision, don't bother generalising it at all.

On pKVM vs CCA guests, there's really nothing specific here to pKVM guests. The only difference is that confidential guests that so far have run without a swiotlb buffer will regress if their memory is tight. For confidential guests without dedicated rmem (either CCA or pKVM), I think our options are either command line swiotlb sizing or dynamic swiotlb.

Could you respin your series while leaving out the generic sizing? IOW, no x86 code generalisation. We can discuss the best strategy on sizing later (I haven't checked how much of this series still makes sense without the generic sizing).

Quoted 70 lines · Catalin Marinas

Quoted 50 lines · Aneesh Kumar K.V

Quoted 43 lines · Aneesh Kumar K.V

Quoted 32 lines · Will Deacon

Quoted 13 lines · Catalin Marinas

Quoted 5 lines · Will Deacon

Quoted 4 lines · Aneesh Kumar K.V (Arm)

(quoted diff) +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

Quoted 7 lines

Review swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

(quoted diff) +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 4 lines

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Hrm, that does mean that reverting just this part will regress pVMs because they'll suddenly be allocating a tonne more memory for an entirely unused swiotlb buffer. So I think I'd prefer to drop the entire series until this has been worked out properly.

Quoted 4 lines

Another option could be the arch code passing another flag that it doesn't want an encrypted pool (e.g. when running in a pKVM guest) but I don't particularly this either. The arch code doesn't know whether there's an alternative pool.

At that point, the default size may as well be driven by the drivers/virt/coco driver.

Quoted 2 lines

That said, such heuristics should have been a separate patch to make it easier to review/drop.

Quoted 10 lines

I think the only right way to get a semi-accurate heuristic is to take into account the set of dma-capable devices that will use the swiotlb pool, but that's fiddly and should probably be tackled as a separate series. Maybe a simpler hack in that direction would be to take the SWIOTLB_POOL_CC_GUEST if _any_ device is going to use swiotlb? You'll run into the usual problem of not being able to tell if a device is DMA-capable or not, but you could probably look for a global restricted DMA pool and, if that doesn't exist, check for per-device restricted pools on dma-coherent devices (since restricted DMA isn't supported by ACPI) as a reasonable approximation.

Quoted 6 lines

So, something like this?

	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
	    swiotlb_cc_guest_needs_default_pool())
		return SWIOTLB_POOL_CC_GUEST;

Quoted 8 lines

Detecting a DMA-capable device is not straightforward, and if we get it wrong, we will enable SWIOTLB_POOL_CC_GUEST unnecessarily. Would the code below be a reasonable approximation of what you suggested?

Another option would be to make swiotlb_cc_guest_needs_default_pool() a weak function that architectures can override. arm64 pKVM could then use a different scheme (for this patch series default to false). Would that be preferable?

Even the rmem check for each device is still a hack that may bite us in the future (private devices for example would not need swiotlb). I'm thinking more and more of leaving the sizing an arch-specific decision, don't bother generalising it at all.

On pKVM vs CCA guests, there's really nothing specific here to pKVM guests. The only difference is that confidential guests that so far have run without a swiotlb buffer will regress if their memory is tight. For confidential guests without dedicated rmem (either CCA or pKVM), I think our options are either command line swiotlb sizing or dynamic swiotlb.

Quoted 5 lines

Could you respin your series while leaving out the generic sizing? IOW, no x86 code generalisation. We can discuss the best strategy on sizing later (I haven't checked how much of this series still makes sense without the generic sizing).

It would mostly consist of the first three cleanup patches, followed by three patches that replace the addressing_limit argument with flags.

#define SWIOTLB_VERBOSE (1 << 0) /* verbose initialization */
/* Initialize a pool for devices with limited DMA addressing. */
#define SWIOTLB_INIT_ADDRESSING_LIMIT (1 << 1)
/* Initialize a pool that requires architecture remapping. */
#define SWIOTLB_INIT_REMAP (1 << 2)
/* Initialize a pool for DMA to memory-encrypted host or guest memory. */
#define SWIOTLB_INIT_MEM_ENCRYPT (1 << 3)
/* Initialize a pool for unaligned kmalloc bouncing. */
#define SWIOTLB_INIT_KMALLOC (1 << 4)
/* Do not initialize a pool unless SWIOTLB is explicitly required. */
#define SWIOTLB_INIT_DEFAULT_OFF (1 << 5)

This results in the large change below. I'm not sure we want to do this for no real benefit other than making swiotlb_should_init() slightly easier to follow.

static bool __init swiotlb_should_init(unsigned int flags)

{
	if (swiotlb_force_disable)
		return false;

	if (swiotlb_force_bounce)
		return true;

	if (flags & (SWIOTLB_INIT_REMAP | SWIOTLB_INIT_MEM_ENCRYPT)))
		return true;

	/* Explicit requirements override an architecture's default opt-out. */
	if (flags & SWIOTLB_INIT_DEFAULT_OFF)
		return false;

	return flags & (SWIOTLB_INIT_ADDRESSING_LIMIT | SWIOTLB_INIT_KMALLOC);
}

Marek,

Patch 3 is a fix, so you may want to take it even if we drop the rest of the series. Perhaps the first three patches could be taken together?

Quoted 2 lines · Aneesh Kumar K.V

Patch 3 is a fix, so you may want to take it even if we drop the rest of the series. Perhaps the first three patches could be taken together?

Okay, I will take only the first 3 patches to dma-mapping-for-next branch now and wait for the remaining patches until they gets sorted out.

Quoted 78 lines · Catalin Marinas

Quoted 57 lines · Aneesh Kumar K.V

Quoted 49 lines · Aneesh Kumar K.V

Quoted 37 lines · Will Deacon

Quoted 15 lines · Catalin Marinas

Quoted 5 lines · Will Deacon

Quoted 4 lines · Aneesh Kumar K.V (Arm)

(quoted diff) +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

Quoted 8 lines

Review swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

(quoted diff) +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 4 lines

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Hrm, that does mean that reverting just this part will regress pVMs because they'll suddenly be allocating a tonne more memory for an entirely unused swiotlb buffer. So I think I'd prefer to drop the entire series until this has been worked out properly.

Quoted 4 lines

Another option could be the arch code passing another flag that it doesn't want an encrypted pool (e.g. when running in a pKVM guest) but I don't particularly this either. The arch code doesn't know whether there's an alternative pool.

At that point, the default size may as well be driven by the drivers/virt/coco driver.

Quoted 2 lines

That said, such heuristics should have been a separate patch to make it easier to review/drop.

Quoted 10 lines

I think the only right way to get a semi-accurate heuristic is to take into account the set of dma-capable devices that will use the swiotlb pool, but that's fiddly and should probably be tackled as a separate series. Maybe a simpler hack in that direction would be to take the SWIOTLB_POOL_CC_GUEST if _any_ device is going to use swiotlb? You'll run into the usual problem of not being able to tell if a device is DMA-capable or not, but you could probably look for a global restricted DMA pool and, if that doesn't exist, check for per-device restricted pools on dma-coherent devices (since restricted DMA isn't supported by ACPI) as a reasonable approximation.

Quoted 6 lines

So, something like this?

	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
	    swiotlb_cc_guest_needs_default_pool())
		return SWIOTLB_POOL_CC_GUEST;

Quoted 8 lines

Detecting a DMA-capable device is not straightforward, and if we get it wrong, we will enable SWIOTLB_POOL_CC_GUEST unnecessarily. Would the code below be a reasonable approximation of what you suggested?

Another option would be to make swiotlb_cc_guest_needs_default_pool() a weak function that architectures can override. arm64 pKVM could then use a different scheme (for this patch series default to false). Would that be preferable?

Even the rmem check for each device is still a hack that may bite us in the future (private devices for example would not need swiotlb). I'm thinking more and more of leaving the sizing an arch-specific decision, don't bother generalising it at all.

On pKVM vs CCA guests, there's really nothing specific here to pKVM guests. The only difference is that confidential guests that so far have run without a swiotlb buffer will regress if their memory is tight. For confidential guests without dedicated rmem (either CCA or pKVM), I think our options are either command line swiotlb sizing or dynamic swiotlb.

Quoted 5 lines

Could you respin your series while leaving out the generic sizing? IOW, no x86 code generalisation. We can discuss the best strategy on sizing later (I haven't checked how much of this series still makes sense without the generic sizing).

It would mostly consist of the first three cleanup patches, followed by three patches that replace the addressing_limit argument with flags.

#define SWIOTLB_VERBOSE (1 << 0) /* verbose initialization */
/* Initialize a pool for devices with limited DMA addressing. */
#define SWIOTLB_INIT_ADDRESSING_LIMIT (1 << 1)
/* Initialize a pool that requires architecture remapping. */
#define SWIOTLB_INIT_REMAP (1 << 2)
/* Initialize a pool for DMA to memory-encrypted host or guest memory. */
#define SWIOTLB_INIT_MEM_ENCRYPT (1 << 3)
/* Initialize a pool for unaligned kmalloc bouncing. */
#define SWIOTLB_INIT_KMALLOC (1 << 4)
/* Do not initialize a pool unless SWIOTLB is explicitly required. */
#define SWIOTLB_INIT_DEFAULT_OFF (1 << 5)

This results in the large change below. I'm not sure we want to do this for no real benefit other than making swiotlb_should_init() slightly easier to follow.

static bool __init swiotlb_should_init(unsigned int flags)

{
	if (swiotlb_force_disable)
		return false;

	if (swiotlb_force_bounce)
		return true;

	if (flags & (SWIOTLB_INIT_REMAP | SWIOTLB_INIT_MEM_ENCRYPT)))
		return true;

	/* Explicit requirements override an architecture's default opt-out. */
	if (flags & SWIOTLB_INIT_DEFAULT_OFF)
		return false;

	return flags & (SWIOTLB_INIT_ADDRESSING_LIMIT | SWIOTLB_INIT_KMALLOC);
}

[...]

Quoted 122 lines · Aneesh Kumar K.V

Quoted 78 lines · Catalin Marinas

Quoted 57 lines · Aneesh Kumar K.V

Quoted 49 lines · Aneesh Kumar K.V

Quoted 37 lines · Will Deacon

Quoted 15 lines · Catalin Marinas

Quoted 5 lines · Will Deacon

Quoted 4 lines · Aneesh Kumar K.V (Arm)

(quoted diff) +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

Quoted 8 lines

Review swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

(quoted diff) +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 4 lines

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Hrm, that does mean that reverting just this part will regress pVMs because they'll suddenly be allocating a tonne more memory for an entirely unused swiotlb buffer. So I think I'd prefer to drop the entire series until this has been worked out properly.

Quoted 4 lines

Another option could be the arch code passing another flag that it doesn't want an encrypted pool (e.g. when running in a pKVM guest) but I don't particularly this either. The arch code doesn't know whether there's an alternative pool.

At that point, the default size may as well be driven by the drivers/virt/coco driver.

Quoted 2 lines

That said, such heuristics should have been a separate patch to make it easier to review/drop.

Quoted 10 lines

I think the only right way to get a semi-accurate heuristic is to take into account the set of dma-capable devices that will use the swiotlb pool, but that's fiddly and should probably be tackled as a separate series. Maybe a simpler hack in that direction would be to take the SWIOTLB_POOL_CC_GUEST if _any_ device is going to use swiotlb? You'll run into the usual problem of not being able to tell if a device is DMA-capable or not, but you could probably look for a global restricted DMA pool and, if that doesn't exist, check for per-device restricted pools on dma-coherent devices (since restricted DMA isn't supported by ACPI) as a reasonable approximation.

Quoted 6 lines

So, something like this?

	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
	    swiotlb_cc_guest_needs_default_pool())
		return SWIOTLB_POOL_CC_GUEST;

Quoted 8 lines

Detecting a DMA-capable device is not straightforward, and if we get it wrong, we will enable SWIOTLB_POOL_CC_GUEST unnecessarily. Would the code below be a reasonable approximation of what you suggested?

Another option would be to make swiotlb_cc_guest_needs_default_pool() a weak function that architectures can override. arm64 pKVM could then use a different scheme (for this patch series default to false). Would that be preferable?

Even the rmem check for each device is still a hack that may bite us in the future (private devices for example would not need swiotlb). I'm thinking more and more of leaving the sizing an arch-specific decision, don't bother generalising it at all.

On pKVM vs CCA guests, there's really nothing specific here to pKVM guests. The only difference is that confidential guests that so far have run without a swiotlb buffer will regress if their memory is tight. For confidential guests without dedicated rmem (either CCA or pKVM), I think our options are either command line swiotlb sizing or dynamic swiotlb.

Quoted 5 lines

Could you respin your series while leaving out the generic sizing? IOW, no x86 code generalisation. We can discuss the best strategy on sizing later (I haven't checked how much of this series still makes sense without the generic sizing).

It would mostly consist of the first three cleanup patches, followed by three patches that replace the addressing_limit argument with flags.

#define SWIOTLB_VERBOSE (1 << 0) /* verbose initialization */
/* Initialize a pool for devices with limited DMA addressing. */
#define SWIOTLB_INIT_ADDRESSING_LIMIT (1 << 1)
/* Initialize a pool that requires architecture remapping. */
#define SWIOTLB_INIT_REMAP (1 << 2)
/* Initialize a pool for DMA to memory-encrypted host or guest memory. */
#define SWIOTLB_INIT_MEM_ENCRYPT (1 << 3)
/* Initialize a pool for unaligned kmalloc bouncing. */
#define SWIOTLB_INIT_KMALLOC (1 << 4)
/* Do not initialize a pool unless SWIOTLB is explicitly required. */
#define SWIOTLB_INIT_DEFAULT_OFF (1 << 5)

This results in the large change below. I'm not sure we want to do this for no real benefit other than making swiotlb_should_init() slightly easier to follow.

static bool __init swiotlb_should_init(unsigned int flags)

{
	if (swiotlb_force_disable)
		return false;

	if (swiotlb_force_bounce)
		return true;

	if (flags & (SWIOTLB_INIT_REMAP | SWIOTLB_INIT_MEM_ENCRYPT)))
		return true;

	/* Explicit requirements override an architecture's default opt-out. */
	if (flags & SWIOTLB_INIT_DEFAULT_OFF)
		return false;

	return flags & (SWIOTLB_INIT_ADDRESSING_LIMIT | SWIOTLB_INIT_KMALLOC);
}

Quoted 1 line

[...]

Hi Aneesh,

I can reproduce the CCA regression discussed in this thread:
https://lore.kernel.org/all/[email protected]/#t

The guest runs out of SWIOTLB slots, causing disk I/O to fail and preventing the guest from booting.

I would like to test the fix on real CCA hardware. Could you please Cc me when you respin the series? I follow LKML, but I may still miss the posting by chance.

Quoted 9 lines

Hi Aneesh,

I can reproduce the CCA regression discussed in this thread:
https://lore.kernel.org/all/[email protected]/#t

The guest runs out of SWIOTLB slots, causing disk I/O to fail and preventing the guest from booting.

Quoted 4 lines

I would like to test the fix on real CCA hardware. Could you please Cc me when you respin the series? I follow LKML, but I may still miss the posting by chance.

The conclusion was to either use CONFIG_SWIOTLB_DYNAMIC or swiotlb kernel command line option

Quoted 13 lines · Catalin Marinas

Quoted 12 lines · Will Deacon

kernel/dma/swiotlb.c swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 8 lines · Aneesh Kumar K.V (Arm)

kernel/dma/swiotlb.c +2 -1

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 
-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

Quoted 4 lines

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Hrm, that does mean that reverting just this part will regress pVMs because they'll suddenly be allocating a tonne more memory for an entirely unused swiotlb buffer. So I think I'd prefer to drop the entire series until this has been worked out properly.

Quoted 18 lines · Will Deacon

Quoted 17 lines · Catalin Marinas

Quoted 5 lines · Will Deacon

Quoted 4 lines · Aneesh Kumar K.V (Arm)

kernel/dma/swiotlb.c +0 -0

@@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
 	if (swiotlb_force_disable)
 		return SWIOTLB_POOL_NONE;
 

Quoted 7 lines

kernel/dma/swiotlb.c swiotlb_select_pool_policy(unsigned int flags) · line 521

Quoted 4 lines

kernel/dma/swiotlb.c +2 -1

-	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
+	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+	    !restricted_dma_pool_present)
 		return SWIOTLB_POOL_CC_GUEST;

I think this check on the restricted DMA pool is too general -- the pool could be tied to a specific DMA-capable peripheral and so treating its presence as a global property isn't right.

I agree it's a hack but that was the simplest way to avoid the pVMs getting a bounce buffer after this patch. More than happy to leave it out and reduce the buffer on cmdline or we come up with some better heuristics.

Quoted 4 lines

Hrm, that does mean that reverting just this part will regress pVMs because they'll suddenly be allocating a tonne more memory for an entirely unused swiotlb buffer. So I think I'd prefer to drop the entire series until this has been worked out properly.

I've dropped the entire series from dma-mapping-for-next. Aneesh, please respin it again and move the pKVM/restricted_dma_pool related code into the separate patch.

Quoted 1 line · Will Deacon

On Thu, Sep 24, 2026 at 11:37:54AM +0530, Aneesh Kumar K.V (Arm) wrote:

That said, such heuristics should have been a separate patch to make it easier to review/drop.

This series centralizes swiotlb default-pool selection and sizing, and simplifies the initialization flags used to describe pool placement.

The first patch replaces the addressing-limit argument with initialization flags and introduces explicit policies for the different reasons a default pool may be needed. Architectures now report DMA addressing constraints with SWIOTLB_INIT_ADDRESSING_LIMIT, while the core selects the corresponding pool policy.

The second patch moves the reduced sizing used when the pool is needed only for unaligned kmalloc bouncing from arm64 and RISC-V into the swiotlb core.

The third patch centralizes swiotlb sizing for memory-encrypted systems. It moves the existing x86 guest-sizing policy into the core. Host memory encryption retains the normal pool size, and a shared default pool is not selected solely for guest memory encryption when a restricted DMA pool is present.

The fourth patch removes SWIOTLB_ANY. Pool placement is derived directly from SWIOTLB_INIT_ADDRESSING_LIMIT: pools required for limited DMA addressing are allocated below the architecture's low address limit, while other pools may be allocated anywhere in directly mapped memory. Xen continues to request a pool explicitly with SWIOTLB_INIT_REMAP without imposing a low-address constraint.

...

 Documentation/core-api/swiotlb.rst   |   8 +-
 arch/arm/mm/init.c                   |   6 +-
 arch/arm/xen/mm.c                    |   2 +-
 arch/arm64/mm/init.c                 |  14 +-
 arch/loongarch/kernel/setup.c        |   2 +-
 arch/mips/cavium-octeon/dma-octeon.c |   2 +-
 arch/mips/loongson64/dma.c           |   2 +-
 arch/mips/sibyte/common/dma.c        |   2 +-
 arch/powerpc/kernel/dma-swiotlb.c    |   4 +-
 arch/powerpc/mm/mem.c                |  17 ++-
 arch/powerpc/platforms/pseries/svm.c |  10 --
 arch/powerpc/sysdev/fsl_pci.c        |   1 +

 arch/riscv/mm/init.c                 |  24 +---
 arch/s390/mm/init.c                  |   2 +-
 arch/x86/include/asm/crash_reserve.h |   4 +-
 arch/x86/kernel/pci-dma.c            |  23 +++-
 arch/x86/mm/mem_encrypt.c            |  24 ----
 include/linux/swiotlb.h              |  17 ++-
 kernel/dma/swiotlb.c                 | 193 +++++++++++++++++++--------
 19 files changed, 210 insertions(+), 147 deletions(-)

This series centralizes swiotlb default-pool selection and sizing, and simplifies the initialization flags used to describe pool placement.

The first patch replaces the addressing-limit argument with initialization flags and introduces explicit policies for the different reasons a default pool may be needed. Architectures now report DMA addressing constraints with SWIOTLB_INIT_ADDRESSING_LIMIT, while the core selects the corresponding pool policy.

The second patch moves the reduced sizing used when the pool is needed only for unaligned kmalloc bouncing from arm64 and RISC-V into the swiotlb core.

The third patch centralizes swiotlb sizing for memory-encrypted systems. It moves the existing x86 guest-sizing policy into the core. Host memory encryption retains the normal pool size, and a shared default pool is not selected solely for guest memory encryption when a restricted DMA pool is present.

The fourth patch removes SWIOTLB_ANY. Pool placement is derived directly from SWIOTLB_INIT_ADDRESSING_LIMIT: pools required for limited DMA addressing are allocated below the architecture's low address limit, while other pools may be allocated anywhere in directly mapped memory. Xen continues to request a pool explicitly with SWIOTLB_INIT_REMAP without imposing a low-address constraint.

Quoted 18 lines · Aneesh Kumar K.V (Arm)

This series centralizes swiotlb default-pool selection and sizing, and simplifies the initialization flags used to describe pool placement.

The first patch replaces the addressing-limit argument with initialization flags and introduces explicit policies for the different reasons a default pool may be needed. Architectures now report DMA addressing constraints with SWIOTLB_INIT_ADDRESSING_LIMIT, while the core selects the corresponding pool policy.

The second patch moves the reduced sizing used when the pool is needed only for unaligned kmalloc bouncing from arm64 and RISC-V into the swiotlb core.

The third patch centralizes swiotlb sizing for memory-encrypted systems. It moves the existing x86 guest-sizing policy into the core. Host memory encryption retains the normal pool size, and a shared default pool is not selected solely for guest memory encryption when a restricted DMA pool is present.

Quoted 6 lines

The fourth patch removes SWIOTLB_ANY. Pool placement is derived directly from SWIOTLB_INIT_ADDRESSING_LIMIT: pools required for limited DMA addressing are allocated below the architecture's low address limit, while other pools may be allocated anywhere in directly mapped memory. Xen continues to request a pool explicitly with SWIOTLB_INIT_REMAP without imposing a low-address constraint.

I will give this patchset a chance in linux-next. If one feels that it still needs to be improved or sees any other reason why it shouldn't be merged, let me know asap.