From: Mostafa Saleh <smostafa@google.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
Robin Murphy <robin.murphy@arm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Steven Price <steven.price@arm.com>,
Suzuki K Poulose <Suzuki.Poulose@arm.com>,
Jiri Pirko <jiri@resnulli.us>, Jason Gunthorpe <jgg@ziepe.ca>,
Petr Tesarik <ptesarik@suse.com>,
Alexey Kardashevskiy <aik@amd.com>,
Dan Williams <dan.j.williams@intel.com>,
Xu Yilun <yilun.xu@linux.intel.com>
Subject: Re: [PATCH v3 0/9] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
Date: Mon, 11 May 2026 11:13:43 +0000 [thread overview]
Message-ID: <agG557zSEmAqp1mn@google.com> (raw)
In-Reply-To: <af4dK-0HEsKdPAvM@arm.com>
On Fri, May 08, 2026 at 06:28:11PM +0100, Catalin Marinas wrote:
> On Mon, Apr 27, 2026 at 11:25:00AM +0530, Aneesh Kumar K.V (Arm) wrote:
> > This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
> > dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
> > are handled consistently.
>
> I think this series makes sense, using DMA_ATTR_CC_SHARED throughout the
> DMA API, either for alloc or for streaming to decide/check what bouncing
> does. Sashiko has a few interesting reports, it probably breaks s390 as
> well (it might be similar to the pKVM case).
I have this series on my review list, I believe there is an overlap with
my series, I can rebase mine on top of this if that makes sense, I will
probably wait for a new version to address the current comments and
Sashiko notes.
Thanks,
Mostafa
>
> I don't think it addresses earlier Mostafa's issues with pKVM, although
> I'd rather base additional pKVM related fixes on top of this series.
> With pKVM, cc_platform_has(CC_ATTR_MEM_ENCRYPT) returns false, as does
> force_dma_unencrypted(). I think we should update protected guests to
> return true for these if they need shared buffers (the whole
> decrypted/shared terminology is messy but in most places it just means
> buffer not private to the protected guest, whether encryption is
> available or not).
>
> That said, does CC_ATTR_GUEST_MEM_ENCRYPT actually make more sense than
> CC_ATTR_MEM_ENCRYPT throughout this series? We'd need to change arm64
> realms as well to use this one.
>
> --
> Catalin
next prev parent reply other threads:[~2026-05-11 11:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 5:55 [PATCH v3 0/9] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths Aneesh Kumar K.V (Arm)
2026-04-27 5:55 ` [PATCH v3 1/9] dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages Aneesh Kumar K.V (Arm)
2026-04-27 5:55 ` [PATCH v3 2/9] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths Aneesh Kumar K.V (Arm)
2026-05-08 9:26 ` Catalin Marinas
2026-05-11 5:38 ` Aneesh Kumar K.V
2026-04-27 5:55 ` [PATCH v3 3/9] dma-pool: track decrypted atomic pools and select them via attrs Aneesh Kumar K.V (Arm)
2026-04-27 5:55 ` [PATCH v3 4/9] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-05-08 16:49 ` Catalin Marinas
2026-05-11 5:14 ` Aneesh Kumar K.V
2026-04-27 5:55 ` [PATCH v3 5/9] dma-mapping: make dma_pgprot() " Aneesh Kumar K.V (Arm)
2026-04-27 5:55 ` [PATCH v3 6/9] dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks Aneesh Kumar K.V (Arm)
2026-04-27 5:55 ` [PATCH v3 7/9] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-04-27 5:55 ` [PATCH v3 8/9] dma-direct: set decrypted flag for remapped DMA allocations Aneesh Kumar K.V (Arm)
2026-04-27 5:55 ` [PATCH v3 9/9] dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-05-08 17:28 ` [PATCH v3 0/9] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths Catalin Marinas
2026-05-10 0:36 ` Jason Gunthorpe
2026-05-11 11:13 ` Mostafa Saleh [this message]
2026-05-12 12:42 ` Jason Gunthorpe
2026-05-11 11:18 ` Aneesh Kumar K.V
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=agG557zSEmAqp1mn@google.com \
--to=smostafa@google.com \
--cc=Suzuki.Poulose@arm.com \
--cc=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dan.j.williams@intel.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=ptesarik@suse.com \
--cc=robin.murphy@arm.com \
--cc=steven.price@arm.com \
--cc=will@kernel.org \
--cc=yilun.xu@linux.intel.com \
/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.