On Thu, Aug 13, 2026 at 11:02:17AM +0530, Aneesh Kumar K.V wrote: > 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.
Maybe, but that's for a different discussion (and we may want different sizing). Better to keep the semantics unchanged for now. > >> > 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]/ You might want to bring this early together with the swiotlb adjustment here. > >> 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. Sound good. > > 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. Great. Now you have a 3-patch series for the generic swiotlb sizing ;) -- Catalin
