linux-hardening - Re: [PATCH v7 00/11] vfio/pci: Allow MMIO regions to be exported through dma-buf

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: <3599880e-5b50-4bad-949b-0d3b1fb25f3f@amd.com>
Date: Tue, 18 Nov 2025 15:37:41 +0100
From: Christian König <christian.koenig@....com>
To: Jason Gunthorpe <jgg@...pe.ca>, Alex Williamson <alex@...zbot.org>
Cc: Leon Romanovsky <leon@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Logan Gunthorpe <logang@...tatee.com>, Jens Axboe <axboe@...nel.dk>,
 Robin Murphy <robin.murphy@....com>, Joerg Roedel <joro@...tes.org>,
 Will Deacon <will@...nel.org>, Marek Szyprowski <m.szyprowski@...sung.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Jonathan Corbet <corbet@....net>,
 Sumit Semwal <sumit.semwal@...aro.org>, Kees Cook <kees@...nel.org>,
 "Gustavo A. R. Silva" <gustavoars@...nel.org>,
 Ankit Agrawal <ankita@...dia.com>, Yishai Hadas <yishaih@...dia.com>,
 Shameer Kolothum <skolothumtho@...dia.com>, Kevin Tian
 <kevin.tian@...el.com>, Krishnakant Jaju <kjaju@...dia.com>,
 Matt Ochs <mochs@...dia.com>, linux-pci@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
 iommu@...ts.linux.dev, linux-mm@...ck.org, linux-doc@...r.kernel.org,
 linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linaro-mm-sig@...ts.linaro.org, kvm@...r.kernel.org,
 linux-hardening@...r.kernel.org, Alex Mastro <amastro@...com>,
 Nicolin Chen <nicolinc@...dia.com>,
 Vivek Kasireddy <vivek.kasireddy@...el.com>
Subject: Re: [PATCH v7 00/11] vfio/pci: Allow MMIO regions to be exported
 through dma-buf

On 11/17/25 18:16, Jason Gunthorpe wrote:
> On Mon, Nov 17, 2025 at 08:36:20AM -0700, Alex Williamson wrote:
>> On Tue, 11 Nov 2025 09:54:22 +0100
>> Christian König <christian.koenig@....com> wrote:
>>
>>> On 11/10/25 21:42, Alex Williamson wrote:
>>>> On Thu,  6 Nov 2025 16:16:45 +0200
>>>> Leon Romanovsky <leon@...nel.org> wrote:
>>>>   
>>>>> Changelog:
>>>>> v7:
>>>>>  * Dropped restore_revoke flag and added vfio_pci_dma_buf_move
>>>>>    to reverse loop.
>>>>>  * Fixed spelling errors in documentation patch.
>>>>>  * Rebased on top of v6.18-rc3.
>>>>>  * Added include to stddef.h to vfio.h, to keep uapi header file independent.  
>>>>
>>>> I think we're winding down on review comments.  It'd be great to get
>>>> p2pdma and dma-buf acks on this series.  Otherwise it's been posted
>>>> enough that we'll assume no objections.  Thanks,  
>>>
>>> Already have it on my TODO list to take a closer look, but no idea when that will be.
>>>
>>> This patch set is on place 4 or 5 on a rather long list of stuff to review/finish.
>>
>> Hi Christian,
>>
>> Gentle nudge.  Leon posted v8[1] last week, which is not drawing any
>> new comments.  Do you foresee having time for review that I should
>> still hold off merging for v6.19 a bit longer?  Thanks,
> 
> I really want this merged this cycle, along with the iommufd part,
> which means it needs to go into your tree by very early next week on a
> shared branch so I can do the iommufd part on top.
> 
> It is the last blocking kernel piece to conclude the viommu support
> roll out into qemu for iommufd which quite a lot of people have been
> working on for years now.
> 
> IMHO there is nothing profound in the dmabuf patch, it was written by
> the expert in the new DMA API operation, and doesn't form any
> troublesome API contracts. It is also the same basic code as from the
> v1 in July just moved into dmabuf .c files instead of vfio .c files at
> Christoph's request.

As long as it is only an internal API between iommu and vfio which also respects the standard DMA-buf semantics to either pin buffers or provide a move_notify interface then feel free to go ahead with it.

Skimming over it my only concern is patch #6 which adds the helper to the common DMA-buf code and that in turn would need an in-deep review which I currently don't have time for.

So if we could keep those inside the VFIO driver for now I think that should be good to go.

Regards,
Christian.

> My hope is DRM folks will pick up the baton and continue to improve
> this to move other drivers away from dma_map_resource(). Simona told
> me people have wanted DMA API improvements for ages, now we have them,
> now is the time!
> 
> Any remarks after the fact can be addressed incrementally.
> 
> If there are no concrete technical remarks please take it. 6 months is
> long enough to wait for feedback.
> 
> Thanks,
> Jason