Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices

[Alexey Kardashevskiy]

On 28/2/26 11:06, Jason Gunthorpe wrote:
> On Wed, Feb 25, 2026 at 05:08:37PM +0000, Robin Murphy wrote:
>
> > I guess this comes back to the point I just raised on the previous patch -
> > the current assumption is that devices cannot access private memory at all,
> > and thus phys_to_dma() is implicitly only dealing with the mechanics of how
> > the given device accesses shared memory. Once that no longer holds, I don't
> > see how we can find the right answer without also consulting the relevant
> > state of paddr itself, and that really *should* be able to be commonly
> > abstracted across CoCo environments.
>
> Definately, I think building on this is a good place to start
>
> https://lore.kernel.org/all/20260223095136.225277-2-jiri@xxxxxxxxxxx/

cool, thanks for the pointer.

> Probably this series needs to take DMA_ATTR_CC_DECRYPTED and push it
> down into the phys_to_dma() and make the swiotlb shared allocation
> code force set it.
>
> But what value is stored in the phys_addr_t for shared pages on the
> three arches? Does ARM and Intel set the high GPA/IPA bit in the
> phys_addr or do they set it through the pgprot? What does AMD do?
> ie can we test a bit in the phys_addr_t to reliably determine if it is
> shared or private?

Without secure vIOMMU, no Cbit in the S2 table (==host) for any VM. SDTE (==IOMMU) decides on shared/private for the device, i.e. (device_cc_accepted()?private:shared).

With secure vIOMMU, PTEs in VM will or won't have the SME mask.

> > > pci_device_add() enforces the FFFF_FFFF coherent DMA mask so
> > > dma_alloc_coherent() fails when SME=on, this is how I ended up fixing
> > > phys_to_dma() and not quite sure it is the right fix.
>
> Does AMD have the shared/private GPA split like ARM and Intel do? Ie
> shared is always at a high GPA? What is the SME mask?

sorry but I do not follow this entirely.

In general, GPA != DMA handle. Cbit (bit51) is not an address bit in a GPA but it is a DMA handle so I mask it there.

With one exception - 1) host 2) mem_encrypt=on 3) iommu=pt, but we default to IOMMU in the case of host+mem_encrypt=on and don't have Cbit in host's DMA handles.

For CoCoVM, I could map everything again at the 1<<51 offset in the same S2 table to leak Cbit to the bus (useless though).

There is vTOM in SDTE which is "every phys_addr_t above vTOM is no Cbit, below - with Cbit" (and there is the same thing for the CPU side in SEV) but this not it, right?

AMD's SME mask for shared is 0, for private - 1<<51.

Thanks,


--
Alexey