public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Christian König" <christian.koenig@amd.com>,
	"Alex Williamson" <alex@shazbot.org>
Cc: "Leon Romanovsky" <leon@kernel.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Chia-I Wu" <olvaffe@gmail.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Kevin Tian" <kevin.tian@intel.com>,
	"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Felix Kuehling" <Felix.Kuehling@amd.com>,
	"Ankit Agrawal" <ankita@nvidia.com>,
	"Vivek Kasireddy" <vivek.kasireddy@intel.com>,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
	amd-gfx@lists.freedesktop.org, virtualization@lists.linux.dev,
	intel-xe@lists.freedesktop.org, linux-rdma@vger.kernel.org,
	iommu@lists.linux.dev, kvm@vger.kernel.org
Subject: Re: [PATCH v5 4/8] vfio: Wait for dma-buf invalidation to complete
Date: Mon, 2 Feb 2026 11:55:11 -0400	[thread overview]
Message-ID: <20260202155511.GI2328995@ziepe.ca> (raw)
In-Reply-To: <44ec9689-045e-401b-b9cc-17abdd938bc7@amd.com>

On Mon, Feb 02, 2026 at 04:21:50PM +0100, Christian König wrote:
> > I admit I don't know a lot about VFIO PM support.. Though I thought in
> > the VFIO case PM was actually under userspace control as generally the
> > PM control is delegated to the VM.
> > 
> > Through that lens, what is happening here is correct. If the VM
> > requests to shut down VFIO PM (through a hypervisor vfio ioctl) then
> > we do want to revoke the DMABUF so that the VM can't trigger a AER/etc
> > by trying to access the sleeping PCI device.
> > 
> > I don't think VFIO uses automatic PM on a timer, that doesn't make
> > sense for it's programming model.
> 
> From your description I agree that this doesn't make sense, but from
> the code it looks like exactly that is done.
> 
> Grep for pm_runtime_* on drivers/vfio/pci, but could be that I
> misunderstood the functionality, e.g. didn't spend to much time on
> it.
> 
> Just keep it in the back of your mind and maybe double check if that
> is actually the desired behavior.

I had a small conversation with AlexW and we think VFIO is OK (bugs
excluded).

The use of the PM timer is still under userspace control, even though
a timer is still involved.

Basically there are a series of IOCTL defined in VFIO, like
LOW_POWER_ENTRY that all isolate the PCI device from userspace. The
mmap is blocked with SIBGUS and the DMABUFs are revoked.

The VFIO uAPI contract requries userspace to stop touching the device
immediately when using these IOCTLs. The PM timer may still be
involved, but is an implementation detail.

Effectively VFIO has a device state "isolated" meaning that userspace
cannot access the MMIO, and it enters this state based on various
IOCTLs from userspace. It ties mmap and DMABUF together so that if
mmap SIGBUS's the DMABUF is unmapped.

I understand your remarks, and this use of PM is certainly nothing
that any other driver should copy, but it does make sense for VFIO. If
there are bugs/issues we would continue to keep the overall property
that SGIBUS==DMABUF unmapped and only adjust when that happens.

TBH, I don't think people use the VFIO PM feature very much.

Jason

  reply	other threads:[~2026-02-02 15:55 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-24 19:14 [PATCH v5 0/8] dma-buf: Use revoke mechanism to invalidate shared buffers Leon Romanovsky
2026-01-24 19:14 ` [PATCH v5 1/8] dma-buf: Rename .move_notify() callback to a clearer identifier Leon Romanovsky
2026-01-24 19:14 ` [PATCH v5 2/8] dma-buf: Rename dma_buf_move_notify() to dma_buf_invalidate_mappings() Leon Romanovsky
2026-01-27  9:21   ` Christian König
2026-01-24 19:14 ` [PATCH v5 3/8] dma-buf: Always build with DMABUF_MOVE_NOTIFY Leon Romanovsky
2026-01-27  9:26   ` Christian König
2026-01-27  9:58     ` Leon Romanovsky
2026-01-27 10:02       ` Christian König
2026-01-27 11:42         ` Leon Romanovsky
2026-01-27 20:45           ` Leon Romanovsky
2026-01-30  7:00         ` Leon Romanovsky
2026-01-24 19:14 ` [PATCH v5 4/8] vfio: Wait for dma-buf invalidation to complete Leon Romanovsky
2026-01-26 20:53   ` Pranjal Shrivastava
2026-01-27  8:58     ` Leon Romanovsky
2026-01-27 16:27       ` Jason Gunthorpe
2026-01-29  7:06         ` Tian, Kevin
2026-01-29  7:33           ` Leon Romanovsky
2026-01-29  8:13             ` Tian, Kevin
2026-01-29  8:41               ` Leon Romanovsky
2026-01-29 21:04                 ` Alex Williamson
2026-01-30  3:10                 ` Tian, Kevin
2026-01-29 14:58           ` Jason Gunthorpe
2026-01-30  3:12             ` Tian, Kevin
2026-01-30  5:43               ` Mauro Carvalho Chehab
2026-01-30  5:48                 ` Tian, Kevin
2026-01-30  8:46             ` Christian König
2026-01-30  8:30   ` Christian König
2026-01-30 13:01     ` Leon Romanovsky
2026-01-30 13:21       ` Christian König
2026-01-30 13:31         ` Leon Romanovsky
2026-01-30 13:56         ` Jason Gunthorpe
2026-01-30 14:11           ` Christian König
2026-01-30 14:44             ` Jason Gunthorpe
2026-02-02  8:42               ` Christian König
2026-02-02 15:12                 ` Jason Gunthorpe
2026-02-02 15:21                   ` Christian König
2026-02-02 15:55                     ` Jason Gunthorpe [this message]
2026-01-24 19:14 ` [PATCH v5 5/8] dma-buf: Make .invalidate_mapping() truly optional Leon Romanovsky
2026-01-30  8:30   ` Christian König
2026-01-30 12:55     ` Leon Romanovsky
2026-01-24 19:14 ` [PATCH v5 6/8] dma-buf: Add dma_buf_attach_revocable() Leon Romanovsky
2026-01-26 20:38   ` Pranjal Shrivastava
2026-01-26 21:01     ` Jason Gunthorpe
2026-01-30  8:43   ` Christian König
2026-01-30 14:00     ` Jason Gunthorpe
2026-01-24 19:14 ` [PATCH v5 7/8] vfio: Permit VFIO to work with pinned importers Leon Romanovsky
2026-01-29 21:04   ` Alex Williamson
2026-01-30  3:14   ` Tian, Kevin
2026-01-24 19:14 ` [PATCH v5 8/8] iommufd: Add dma_buf_pin() Leon Romanovsky
2026-01-29  7:08   ` Tian, Kevin
2026-01-30  0:17   ` Jason Gunthorpe

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=20260202155511.GI2328995@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=Felix.Kuehling@amd.com \
    --cc=airlied@gmail.com \
    --cc=alex@shazbot.org \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ankita@nvidia.com \
    --cc=christian.koenig@amd.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gurchetansingh@chromium.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=olvaffe@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tzimmermann@suse.de \
    --cc=virtualization@lists.linux.dev \
    --cc=vivek.kasireddy@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox