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

Alexey Kardashevskiy
2026-03-03T08:20:01Z

On 3/3/26 00:35, Jason Gunthorpe wrote:
> On Mon, Mar 02, 2026 at 04:26:58PM +1100, Alexey Kardashevskiy wrote:
>
>>>> 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).

"no Cbit" here was "there is Cbit in PTe and it is 0", rather than "Cbit is an address bit".

>>> Is this "Cbit" part of the CPU S2 page table address space or is it
>>> actually some PTE bit that says it is "encrypted" ?

afaik it is always (while SNP is enabled) a PTE bit that says "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.
>
> Yes, I understand this.
>
> It seems from your email that the CPU S2 has the Cbit as part of the
> address and the S1 feeds it through to the S2, so it is genuinely has
> two addres spaces?

S1/S2 PTEs have Cbit. Addresses to look up those PTEs - do not.

(both are "addresses" - one in the PTE and another one - to look up the PTE)

> While the IOMMU S1 does not and instead needs a PTE bit which is
> emphatically not an address bit because it does not feed through the
> S2?

afaik IOMMU works the same.

>>> 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.
>
> Well, I think things work more sensibly if you don't have to mangle
> the address..
>
>>> 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.
>
> Same way it knows if there is no S1?

If no S1 - then sDTE decides on Cbit for the entire ASID (with the help of vTOM).

> Why does the S1 change anything?

S1 will have Cbit in individual PTEs, allowing per page control.
>>>> 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,
>
> Weird!!

:)

I understand I am often confusing, trying to unconfuse (including myself)... Thanks,

--
Alexey