Jason Gunthorpe <[email protected]> writes: > 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.
Agreed. This would make the code much simpler. -aneesh
