[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250922175120.GA2547959@ziepe.ca>
Date: Mon, 22 Sep 2025 14:51:20 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Alex Mastro <amastro@...com>
Cc: Mostafa Saleh <smostafa@...gle.com>,
"Tian, Kevin" <kevin.tian@...el.com>,
Keith Busch <kbusch@...nel.org>,
Alex Williamson <alex.williamson@...hat.com>,
Bjorn Helgaas <bhelgaas@...gle.com>, David Reiss <dreiss@...a.com>,
Joerg Roedel <joro@...tes.org>, Leon Romanovsky <leon@...nel.org>,
Li Zhe <lizhe.67@...edance.com>, Mahmoud Adam <mngyadam@...zon.de>,
Philipp Stanner <pstanner@...hat.com>,
Robin Murphy <robin.murphy@....com>,
"Kasireddy, Vivek" <vivek.kasireddy@...el.com>,
Will Deacon <will@...nel.org>, Yunxiang Li <Yunxiang.Li@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [TECH TOPIC] vfio, iommufd: Enabling user space drivers to vend
more granular access to client processes
On Mon, Sep 22, 2025 at 10:46:23AM -0700, Alex Mastro wrote:
> Following a dma_buf_ops.mmap, I suppose that revocation would mean:
I'd investigate adding some ioctl to the dmabuf fd to permanently
revoke it. The zapping/etc already has to be done just to get mmap in
the first place. The vending process would retain a FD on the dmabuf
and when it is time to revoke it then it can call the ioctl directly
on the fd to revoke.
Jason
Powered by blists - more mailing lists