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

[Alexey Kardashevskiy]

On 2/3/26 11:35, Jason Gunthorpe wrote:
> On Mon, Mar 02, 2026 at 11:01:24AM +1100, Alexey Kardashevskiy wrote:
> > 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).
>
> Is this "Cbit" part of the CPU S2 page table address space or is it
> actually some PTE bit that says it is "encrypted" ?
>
> It is confusing when you say it would start working with a vIOMMU.

When I mention vIOMMU, I mean the S1 table which is guest owned and which has Cbit in PTEs.

> If 1<<51 is a valid IOPTE, and it is an actually address, then it
> should be mapped into the IOMMU S2, shouldn't it? If it is in the
> IOMMU S2 then shouldn't it work as a dma_addr_t?

It should (and checked with the HW folks), I just have not tried it  as, like, whyyy.

> If the HW is treating 1<<51 special in some way and not reflecting it
> into a S2 lookup then it isn't an address bit but an IOPTE flag.
> IMHO is really dangerous to intermix PTE flags into phys_addr_t, I
> hope that is not what is happening.
Sounds like what you hope for is how it works now.

> > > 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).
>
> Double map is what ARM does at least. I don't know it is a good
> choice, but it means that phys_addr_t can have a shared/private bit
> (eg your Cbit at 51) and both the CPU and IOMMU S2 have legitimate
> mappings. ie it is a *true* address bit.
>
> Given AMD has only a single IOMMO for T=0 and 1 it would make sense to
> me if AMD always remove the C bit and there is always a uniform IOVA
> mapping from 0 -> vTOM.
>
> But in this case I would expect the vIOMMU to also use the same GPA
> space starting from 0 and also remove the C bit, as the S2 shouldn't
> have mappings starting at 1<<51.

How would then IOMMU know if DMA targets private or shared memory? The Cbit does not participate in the S2 translation as an address bit but IOMMU still knows what it is.

> > 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?
>
> That seems like the IOMMU HW is specially handling the address bits in
> some way?

Yeah there is this capability. Except everything below vTOM is private and every above is shared so SME mask for it would be reverse than the CPU SME mask :) Not using this thing though (not sure why we have it). Thanks,

> At least ARM doesn't have anything like that, address bits
> are address bits, they don't get overloaded with secondary mechanisms.
> > > AMD's SME mask for shared is 0, for private - 1<<51.
>
> ARM is the inverse of this (private is at 0), but the same idea.
>
> Jason

--
Alexey