On Mon, Jun 22, 2026 at 10:58:23AM +1000, Alexey Kardashevskiy wrote:

quoted

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

Encrypted meaning I'm using DRAM encryption on the host and Encrypted
meaning this page is private and inaccessible to the hypervisor are
very different things with very different requirements and is
confusing they have been overloaded in Linux :(

quoted

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.

Sure, I know, it is a gross solution to a self inflict error.

We (AMD) do not really want to force Cbit in DMA handles and
it is not happening unless "iommu=pt".

Lots of real HW won't work will because of this, so yeah you pretty
much have to. But also there is HW that is fine, like you can use a
mlx5 device and it will handle the C bit just fine.

It is pretty hacky to globally force the iommu mode because some
devices end up not working.

quoted

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.

That is how it should ideall work, in this case the purpose of the
swiotlb pool is to provide low dma address memory because the device
cannot reach the normal linux dram addresses.

As you mentioned in another mail in the thread, DMAing to
unencrypted memory with mem_encrypt=on make no sense security
wise. 

Yes, pretty much.

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.

Arguably it should be done per device. The problem is the iommu layer
doesn't know what the dma mask is until the driver binds so it can't
detect a device that is unable to reach any dram and switch away from
identity automatically. That would be much cleaner.

quoted

quoted

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

Ok, but here you have overloaded the word encrypted again :( Decrypted
memory containing ciphertext I think you mean

quoted

quoted

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

Okay, but this has nothing to do with sev-guest at all, and should not
be solved uniquely for it.

The DMA API in general has a problem spraying allocations all over
system memory and fragmenting the RMP/GPT/etc and yes it needs a
solution, but it should be entirely in the DMA API and have no
special involvment with sev-guest. sev-guest should just make coherent
allocations and use them in the normal way.

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

dma_alloc_coherent using the swiotlb pool instead of allocating and
converting in general is a reasonable proposal, IMHO. Again, nothing
to do with sev-guest.

Jason