linux-kernel - Re: [PATCH v7 00/17] Provide a new two step DMA mapping API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c916a21e-2d95-476d-9895-4d91873fc5d5@samsung.com>
Date: Fri, 28 Mar 2025 15:18:39 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Leon Romanovsky <leon@...nel.org>, Robin Murphy <robin.murphy@....com>,
	Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>, Joerg Roedel
	<joro@...tes.org>, Will Deacon <will@...nel.org>, Sagi Grimberg
	<sagi@...mberg.me>, Keith Busch <kbusch@...nel.org>, Bjorn Helgaas
	<bhelgaas@...gle.com>, Logan Gunthorpe <logang@...tatee.com>, Yishai Hadas
	<yishaih@...dia.com>, Shameer Kolothum
	<shameerali.kolothum.thodi@...wei.com>, Kevin Tian <kevin.tian@...el.com>,
	Alex Williamson <alex.williamson@...hat.com>,
	Jérôme Glisse <jglisse@...hat.com>, Andrew Morton
	<akpm@...ux-foundation.org>, Jonathan Corbet <corbet@....net>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-block@...r.kernel.org, linux-rdma@...r.kernel.org,
	iommu@...ts.linux.dev, linux-nvme@...ts.infradead.org,
	linux-pci@...r.kernel.org, kvm@...r.kernel.org, linux-mm@...ck.org, Randy
	Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v7 00/17] Provide a new two step DMA mapping API

On 22.03.2025 01:41, Jason Gunthorpe wrote:
> On Fri, Mar 21, 2025 at 12:52:30AM +0100, Marek Szyprowski wrote:
>>> Christoph's vision was to make a performance DMA API path that could
>>> be used to implement any scatterlist-like data structure very
>>> efficiently without having to teach the DMA API about all sorts of
>>> scatterlist-like things.
>> Thanks for explaining one more motivation behind this patchset!
> Sure, no problem.
>
> To close the loop on the bigger picture here..
>
> When you put the parts together:
>
>   1) dma_map_sg is the only API that is both performant and fully
>      functional
>
>   2) scatterlist is a horrible leaky design and badly misued all over
>      the place. When Logan added SG_DMA_BUS_ADDRESS it became quite
>      clear that any significant changes to scatterlist are infeasible,
>      or at least we'd break a huge number of untestable legacy drivers
>      in the process.
>
>   3) We really want to do full featured performance DMA *without* a
>      struct page. This requires changing scatterlist, inventing a new
>      scatterlist v2 and DMA map for it, or this idea here of a flexible
>      lower level DMA API entry point.
>
>      Matthew has been talking about struct-pageless for a long time now
>      from the block/mm direction using folio & memdesc and this is
>      meeting his work from the other end of the stack by starting to
>      build a way to do DMA on future struct pageless things. This is
>      going to be huge multi-year project but small parts like this need
>      to be solved and agreed to make progress.

Again, thanks for another summary!

>   4) In the immediate moment we still have problems in VFIO, RDMA, and
>      DRM managing P2P transfers because dma_map_resource/page() don't
>      properly work, and we don't have struct pages to use
>      dma_map_sg(). Hacks around the DMA API have been in the kernel for
>      a long time now, we want to see a properly architected solution.

What kind of a fix is needed to dma_map_resource()/dma_unmap_resource() 
API to make it usable with P2P DMA? It looks that this API is closest to 
the mentioned dma_map_phys() and has little clients, so potentially 
changing the function signature should be quite easy.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland