Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths

[Alexey Kardashevskiy <aik@amd.com>]

On 19/6/26 22:03, Jason Gunthorpe wrote:
> 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.
It is a bit in the PTE which says "encrypted", what do you mean by overloaded?...

> 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.

The generic __init iommu_subsys_init(void) calls iommu_set_default_translated() if CC_ATTR_MEM_ENCRYPT (==force the use of IOMMU) and eliminates the bouncing by default, pretty much. We (AMD) do not really want to force Cbit in DMA handles and it is not happening unless "iommu=pt".

> 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.

True.

Although, with "iommu=pt" enabled, dma handles from swiotlb should not have Cbit so these swiotlb pages  have to be unencrypted.

As you mentioned in another mail in the thread, DMAing to unencrypted memory with mem_encrypt=on make no sense security wise. May be enforce either mem_encrypt=on or iommu=pt is allowed at the same time but not both? I am worried though that some weirdo still has a use case for it.


>>> 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?

It is a platform device, presented in SNP VMs as /dev/sev-guest and the guest userspace calls ioctls on it when it needs VM attestation report/certificates/etc.

The sev-guest driver makes calls to the HV (GHCB protocol) to:
1) get report/certificates/measurements from the HV <- this is done via shared memory as the HV writes to it;
2) asks the HV to get the digests from the PSP <- this is done via encrypted memory (buuuut it is software encrypted and as far as the hw is concerned - it is shared - no Cbit, no RMP - these buffers contain plaintext headers of the PSP requests and cyphertext of the request/response body).

>> 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?

/dev/sev-guest uses only shared memory (from the HW standpoint), and it is normally lot less than 1MB. If hugepages are used, then today it allocates 4K pages (they come encrypted and likely backed with a 2M page), the driver converts them to shared to make that GHCB call. The conversion smashes backing 2M page to 4K pages (+RMP +IOPDE as there is possible ongoing DMA), which is a problem (I have mentioned it as "TMPM" before - a hw/fw helper to do the smashing).

The idea here is that if swiotlb is already shared, the sev-guest could use that memory pool.

Thanks,


> 
> Jason

-- 
Alexey