Re: [RFC PATCH] dma: swiotlb: Size shared default pools for memory encryption

[Aneesh Kumar K . V]

Catalin Marinas <catalin.marinas@xxxxxxx> writes:

> On Tue, Aug 11, 2026 at 07:10:56PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> Systems with memory encryption use swiotlb to provide shared or
>> unencrypted buffers for device DMA. Confidential guests may route all
>> DMA through these buffers, while SME hosts use them for devices that
>> cannot address encrypted memory. The default swiotlb pool can therefore
>> be exhausted under I/O-intensive workloads.
>> 
>> Let architectures mark the default swiotlb pool as shared before
>> swiotlb_init().
>
> I thought we wanted even this decision to be moved out of the arch code.
>

Architectures may want to use an unencrypted swiotlb pool for different
reasons, one of them being CC_ATTR_GUEST_MEM_ENCRYPT. x86 hosts also
require unencrypted pool to support SME. We can cover both cases using
CC_ATTR_MEM_ENCRYPT. However, pKVM does not want an unencrypted SWIOTLB
pool. So I was thinking it would be much cleaner to let the architecture
code drive that decision.

>
>> Move the existing x86 sizing policy into generic swiotlb
>> code and add early pool marking for arm64 Realm guests, powerpc secure
>> guests, s390 protected-virtualization guests, and x86 memory-encryption
>> platforms. Use CC_ATTR_MEM_ENCRYPT on x86 to include host SME, whose
>> swiotlb pool must also be decrypted for devices that cannot address
>> encrypted memory.
>
> That's a functional change for x86. For now, I'd keep it to
> CC_ATTR_GUEST_MEM_ENCRYPT.
>
> BTW, why does arm64 report CC_ATTR_MEM_ENCRYPT instead of the GUEST
> option in realms?
>
>> Move the powerpc secure-guest swiotlb enablement before initialization
>> so that the shared pool is allocated with the required flags. pKVM
>> guests continue to use a restricted DMA pool instead of the default
>> swiotlb pool.
>> 
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@xxxxxxxxxx>
>> ---
>>  arch/arm64/mm/init.c                 |  6 ++-
>>  arch/powerpc/mm/mem.c                |  7 +++
>>  arch/powerpc/platforms/pseries/svm.c | 10 ----
>>  arch/s390/mm/init.c                  |  2 +
>>  arch/x86/mm/mem_encrypt.c            | 27 ++--------
>>  include/linux/swiotlb.h              |  7 ++-
>>  kernel/dma/swiotlb.c                 | 73 ++++++++++++++++++++++------
>>  7 files changed, 82 insertions(+), 50 deletions(-)
>> 
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index e308a7cabd12..4c022e8aed43 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -338,8 +338,12 @@ void __init arch_setup_zero_pages(void)
>>  void __init arch_mm_preinit(void)
>>  {
>>  	unsigned int flags = SWIOTLB_VERBOSE;
>> +	/* pKVM uses restricted-dma-pool */
>> +	bool cc_guest = is_realm_world();
>>  
>> -	if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
>> +	if (cc_guest) {
>> +		swiotlb_mark_default_cc_shared();
>> +	} else 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.
>
> With your other reworking, doesn't the core code know the swiotlb will
> be shared? Can it not make the decision to resize at that point based
> solely on CC_ATTR_GUEST_MEM_ENCRYPT?
>
> I also wonder whether we could address Will's pKVM request not to
> allocate a bounce buffer once pKVM guests will start reporting
> CC_ATTR_GUEST_MEM_ENCRYPT. Some simple heuristic: if a
> restricted-dma-pool is advertised in DT (it will end up in
> rmem_swiotlb_setup()), skip resizing the default swiotlb. It's not
> perfect but the bounce buffer can be overridden on the command line.
>

For the same reason I mentioned above, architectures may have different
reasons for setting cc_shared = true. IMHO, it is cleaner to let the
architecture code make that decision before swiotlb_init().

-aneesh