Catalin Marinas <[email protected]> writes: > On Wed, Aug 12, 2026 at 04:38:03PM +0530, Aneesh Kumar K.V wrote: >> Catalin Marinas <[email protected]> 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. > > Yes but in one case it did not do resizing. With your proposal, it now > does swiotlb resizing even for SME. >
Isn't that a bug with x86 SME? I would expect both SME and SEV to require that swiotlb resize. > >> 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. > > Let's not single out pKVM but rather the reason it does not want one - > it relies heavily on restricted mem. If you started a pKVM guest > without rmem in DT, I assume it will need swiotlb to function properly. > It's not a great heuristic (devices may not use rmem) but it preserves > the current behaviour and can be overridden on the command line. > >> > BTW, why does arm64 report CC_ATTR_MEM_ENCRYPT instead of the GUEST >> > option in realms? This is getting fixed in https://lore.kernel.org/all/[email protected]/ > > It's still not clear to me why we went for CC_ATTR_MEM_ENCRYPT instead > of CC_ATTR_GUEST_MEM_ENCRYPT. > This is done for x86 to handle SME. SME also requires an unencrypted swiotlb pool > >> 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(). > > The arch code already reports cc_platform_has(), can we not rely on > this in the core code instead of specific is_realm_world() and a new > SWIOTLB_INIT_CC_SHARED flag or function call? > > We have three different decisions that shouldn't be driven by a single > flag from the arch code: > > 1. allocate default pool > 2. make default pool shared > 3. resize default pool > > (1) is traditionally driven by arch code and that's fine. For (2), the > core code has the information via CC_ATTR_*. For (3), we can enlarge it > based on CC_ATTR_GUEST_MEM_ENCRYPT in combination with rmem (but not > CC_ATTR_MEM_ENCRYPT to keep the current x86 behaviour). > Okay, if the presence of restricted-dma-pool is taken as a hint, we can definitely move that to generic code. I still think not resizing the swiotlb pool on the host for SME is an x86 bug. However, I'll keep it compatible with the current behavior and use CC_ATTR_GUEST_MEM_ENCRYPT for now. We can handle host SME in a separate patch if needed. > > I think we should also move the reduction based on > CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC into the core code. Riscv copied the > same heuristic as arm64, so there's precedent for sharing. I already have a patch doing that. -aneesh
