On Fri, Jun 19, 2026 at 12:05:45PM +1000, Alexey Kardashevskiy wrote: > > > > > IMHO that's an AMD issue, not with the design of this series.. > > > > > > > > > > The series is right, a device that is !force_dma_decrypted() must be > > > > > considerd to be a trusted device and we must never place any DMA > > > > > mappings for a trusted device into shared memory. > > > > > > > > swiotlb=force forces swiotlb, not decryption. > > > > If force_dma_decrypted() == true then swiotlb must allocate from a > > decrypted memory pool. It is right there in the name! > > > > The hypervisor environment should *never* set force_dma_decrypted() > > because all devices can access all hypervisor memory, up to their IOVA > > limits. > > True. But we do not have encrypted swiotlb pool today, right?
"encrypted" is just normal struct page memory, that's the default for swiotlb. I think it was a big mistake for the AMD SME stuff to overload the decrypted/encrypted CC stuff which should mean shared/private in a guest context to also mean things about physical memory encryption in the host. It is really confusing. The SME side is just a bad arch choice, the real world doesn't work well if you set high address bits in your dma_addr_t. I think AMD needs to use those restricted swiotlb pool where it allocates this very special "SME Disabled" memory that will have a low dma_addr_t. Then alloc and bouncing will get memory with a suitable dma_addr_t. This has nothing to do with force_dma_unencrypted() which is only a CC guest concept and nothing else in the OS should ever touch decrypted memory. > > And this is more insane logic. The right fix is to allocate the > > swiotlb bounce from the *encrypted* pools when running on the > > hypervisor which requires undoing this abuse of force_dma_decrypted(). > > +1. > > But how does the kernel decide if it is this swiotlb pool or just > some page which happens to be below the IOVA limit? You mean in swiotlb_tbl_unmap_single() ? It checks the address against the pool's range? > swiotlb can be for bouncing (with all these dma_sync_single_for_cpu) > or, if dev->dma_io_tlb_mem->for_alloc = true, for coherent > allocation (no need in dma_sync_single_for_cpu). > > I am looking for a way to set up my "sev-guest" device such as when Whats a "sev-guest" device? > dma_alloc_attrs(snp_dev->dev,...) happens, it allocates a page from > the shared swiotlb pool (with no actual bouncing) and there is no > obvious way to trick the DMA layer into doing that. Why do you need this? Jason
