Re: [PATCH v2 7/8] dma-direct: set decrypted flag for remapped DMA allocations

[Aneesh Kumar K . V]

Jason Gunthorpe <jgg@xxxxxxxx> writes:

> On Tue, Apr 21, 2026 at 01:54:52PM +0100, Suzuki K Poulose wrote:
>> On 21/04/2026 13:34, Jason Gunthorpe wrote:
>> > On Mon, Apr 20, 2026 at 11:44:14AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> > > Devices that are DMA non-coherent and require a remap were skipping
>> > > dma_set_decrypted(), leaving DMA buffers encrypted even when the device
>> > > requires unencrypted access. Move the call after the if (remap) branch
>> > > so that both the direct and remapped allocation paths correctly mark the
>> > > allocation as decrypted (or fail cleanly) before use.
>> > > 
>> > > Architectures such as arm64 cannot mark vmap addresses as decrypted, and
>> > > highmem pages necessarily require a vmap remap.
>> > 
>> > I don't think I saw an aswer for this, why can't arm accept
>> > pgprot_decrypted() for vmap? It really should, I don't think we should
>> > have these minor pointless arch differences.
>> > 
>> > Suzuki? You mentioned it, can you elaborate?
>> 
>> We can accept pgprot_decrypted(), but this must be done carefully
>> as the backing pages must be first converted to "decrypted" in the
>> linear map (set_memory_decrypted()).
>
> Isn't that the case for any use of pgprot_decrypted? I think that is
> fine and followed by the dma api.
>
>> With that in place, it should be fine. It is,
>> set_memory_decrypted(vmalloc_address) is we don't support.
>
> That makes more sense. Nothing should do that, changing the state of
> memory that is mapped any place other than the linear map is not
> allowed. I understand this is the condition where Intel will machine
> check..
>
> So with that clarification at least the commit message should be
> revised in this patch to not mention vmap.
>

I will update the commit message to clarify this further.

-aneesh