On 19/6/26 01:37, Jason Gunthorpe wrote:
On Thu, Jun 18, 2026 at 09:37:22AM +0100, Aneesh Kumar K.V wrote:
Alexey Kardashevskiy <[email protected]> writes:
On 10/6/26 00:47, Jason Gunthorpe wrote:
On Tue, Jun 09, 2026 at 02:43:08PM +0100, Catalin Marinas wrote:
On Thu, Jun 04, 2026 at 02:09:39PM +0530, Aneesh Kumar K.V (Arm) wrote:
This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
are handled consistently.
Today, the direct DMA path mostly relies on force_dma_unencrypted() for
shared/decrypted buffer handling. This series consolidates the
force_dma_unencrypted() checks in the top-level functions and ensures
that the remaining DMA interfaces use DMA attributes to make the correct
decisions.
Please check Sashiko's reports, it has some good points:
https://sashiko.dev/#/patchset/[email protected]
I think the main one is the swiotlb_tbl_map_single() changes which break
AMD SME host support. There cc_platform_has(CC_ATTR_MEM_ENCRYPT) is true
but force_dma_unencrypted() is false. Normally you'd not end up on this
path but you can have swiotlb=force.
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?
So when I try "mem_encrypt=on iommu=pt swiotlb=force" with this
patchset, it fails to boot. But it boots with a hack like this:
On the host side I expect this to cause swiotlb to allocate encrypted
memory and bounce to it.
u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
dev->bus_dma_limit);
+ /*
+ * With memory encryption enabled, SWIOTLB is marked decrypted.
+ * If SWIOTLB bouncing is forced, treat the device as requiring
+ * decrypted DMA.
+ */
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?
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
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.
Jason
--
Alexey
