From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Mostafa Saleh <smostafa@google.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org,
maz@kernel.org, suzuki.poulose@arm.com, catalin.marinas@arm.com,
jiri@resnulli.us
Subject: Re: [RFC PATCH v3 5/5] dma-mapping: Fix memory decryption issues
Date: Wed, 15 Apr 2026 18:13:17 +0530 [thread overview]
Message-ID: <yq5aldeo9yxm.fsf@kernel.org> (raw)
In-Reply-To: <20260413124248.GJ3694781@ziepe.ca>
Jason Gunthorpe <jgg@ziepe.ca> writes:
> On Mon, Apr 13, 2026 at 12:49:34PM +0530, Aneesh Kumar K.V wrote:
>> > 2) Using phys_to_dma_unencrypted() is not enlighted about already
>> > decrypted memory and will use the wrong functions for that.
>>
>> Can you split this into a separate patch? I’m finding it difficult to
>> understand what the issue is here. Adding the unencrypted flag multiple
>> times to an address is not a problem in itself. Even so, I still do not
>> follow when we would end up doing that.
>
> I think my comments show how to address it right..
>
>> phys_to_dma_direct should depend on the device state.
>
> No, it depends on what state the CPU address is, which in some flows
> would have depended on the device state, but by the time you get to
> generating a dma_addr_t it should be based 100% on the current state
> of the phys_addr and nothing else.
>
> Assuming that a T=0 device must be presented unencrypted memory is an
> easy hack but it doesn't work when we get to T=1 devices that can
> handle both encryped and decrypted memory. Then we need to track it
> explicitly.
>
> The only places we we should check the device state for T=0 is at the
> very top when we decide if we force it to swiotlb and inside swiotlb
> when we decide if the allocation should be decrypted. Everything else
> should flow from tracking the phy's state, and be tied into the new
> DMA ATTR UNENCRYPTED.
>
For things like
#define dma_map_single(d, a, s, r) dma_map_single_attrs(d, a, s, r, 0)
Where do you suggest DMA_ATTR_CC_DECRYPTED be set?
Right now i have it around
static inline dma_addr_t dma_direct_map_phys(struct device *dev,
phys_addr_t phys, size_t size, enum dma_data_direction dir,
unsigned long attrs)
{
dma_addr_t dma_addr;
if (force_dma_unencrypted(dev))
attrs |= DMA_ATTR_CC_DECRYPTED;
I am wondering whether we should do earlier. But we have only audited
dma-direct for memory encryption.
-aneesh
next prev parent reply other threads:[~2026-04-15 12:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 19:47 [RFC PATCH v3 0/5] dma-mapping: Fixes for memory encryption Mostafa Saleh
2026-04-08 19:47 ` [RFC PATCH v3 1/5] swiotlb: Return state of memory from swiotlb_alloc() Mostafa Saleh
2026-04-14 9:25 ` Aneesh Kumar K.V
2026-04-15 20:43 ` Mostafa Saleh
2026-04-16 8:53 ` Aneesh Kumar K.V
2026-04-17 15:05 ` Mostafa Saleh
2026-04-08 19:47 ` [RFC PATCH v3 2/5] dma-mapping: Move encryption in __dma_direct_free_pages() Mostafa Saleh
2026-04-10 17:45 ` Jason Gunthorpe
2026-04-15 20:49 ` Mostafa Saleh
2026-04-16 0:11 ` Jason Gunthorpe
2026-04-17 15:07 ` Mostafa Saleh
2026-04-08 19:47 ` [RFC PATCH v3 3/5] dma-mapping: Decrypt memory on remap Mostafa Saleh
2026-04-14 9:31 ` Aneesh Kumar K.V
2026-04-14 12:22 ` Jason Gunthorpe
2026-04-14 13:13 ` Aneesh Kumar K.V
2026-04-14 13:53 ` Jason Gunthorpe
2026-05-07 17:18 ` Catalin Marinas
2026-05-08 4:03 ` Aneesh Kumar K.V
2026-04-08 19:47 ` [RFC PATCH v3 4/5] dma-mapping: Encapsulate memory state during allocation Mostafa Saleh
2026-04-10 18:05 ` Jason Gunthorpe
2026-04-15 9:38 ` Aneesh Kumar K.V
2026-04-17 15:45 ` Mostafa Saleh
2026-05-07 17:36 ` Catalin Marinas
2026-05-11 10:48 ` Mostafa Saleh
2026-04-08 19:47 ` [RFC PATCH v3 5/5] dma-mapping: Fix memory decryption issues Mostafa Saleh
2026-04-13 7:19 ` Aneesh Kumar K.V
2026-04-13 12:42 ` Jason Gunthorpe
2026-04-15 12:43 ` Aneesh Kumar K.V [this message]
2026-04-15 13:53 ` Jason Gunthorpe
2026-04-14 9:37 ` Aneesh Kumar K.V
2026-04-10 17:43 ` [RFC PATCH v3 0/5] dma-mapping: Fixes for memory encryption Jason Gunthorpe
2026-04-15 20:25 ` Mostafa Saleh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq5aldeo9yxm.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maz@kernel.org \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.