Re: [RFC PATCH v2 2/5] dma-mapping: Use the correct phys_to_dma() for DMA_RESTRICTED_POOL

Aneesh Kumar K.V
2026-04-16T06:50:15Z

Mostafa Saleh <smostafa@google.com> writes:

> On Mon, Apr 13, 2026 at 11:38:36AM +0530, Aneesh Kumar K.V wrote:
>> Mostafa Saleh <smostafa@google.com> writes:
>>
>> > As restricted dma pools are always decrypted, in swiotlb.c it uses
>> > phys_to_dma_unencrypted() for address conversion.
>> >
>> > However, in DMA-direct, calls to phys_to_dma_direct() with
>> > force_dma_unencrypted() returning false, will fallback to
>> > phys_to_dma() which is inconsistent for memory allocated from
>> > restricted dma pools.
>> >
>> > Fixes: f4111e39a52a ("swiotlb: Add restricted DMA alloc/free support")
>> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
>> > ---
>> > kernel/dma/direct.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>> > index 27d804f0473f..1a402bb956d9 100644
>> > --- a/kernel/dma/direct.c
>> > +++ b/kernel/dma/direct.c
>> > @@ -26,7 +26,7 @@ u64 zone_dma_limit __ro_after_init = DMA_BIT_MASK(24);
>> > static inline dma_addr_t phys_to_dma_direct(struct device *dev,
>> > phys_addr_t phys)
>> > {
>> > - if (force_dma_unencrypted(dev))
>> > + if (force_dma_unencrypted(dev) || is_swiotlb_for_alloc(dev))
>> > return phys_to_dma_unencrypted(dev, phys);
>> >
>>
>> So what kind of device is this? Is it a trusted device that needs to use
>> swiotlb in unencrypted form?(is that a valid use case?) Can we add additional comment
>> explaining the type of device for which we are allocating the DMA
>> buffer?
>
> That’s used for devices that use restricted-dma pools which are
> currently always decrypted, typically virtio devices that are emulated
> by the untrusted host.
>

Why would those devices not force unencrypted DMA? Sorry, I may not be
following all the details. The pool itself is decrypted by default, but
the device does not force unencrypted DMA?”

-aneesh