On 2/2/26 16:12, Jason Gunthorpe wrote: > On Mon, Feb 02, 2026 at 09:42:22AM +0100, Christian König wrote: >> On 1/30/26 15:44, Jason Gunthorpe wrote: >>> On Fri, Jan 30, 2026 at 03:11:48PM +0100, Christian König wrote: >>>> On 1/30/26 14:56, Jason Gunthorpe wrote: >>>>> On Fri, Jan 30, 2026 at 02:21:08PM +0100, Christian König wrote: >>>>> >>>>>> That would work for me. >>>>>> >>>>>> Question is if you really want to do it this way? See usually >>>>>> exporters try to avoid blocking such functions. >>>>> >>>>> Yes, it has to be this way, revoke is a synchronous user space >>>>> triggered operation around things like FLR or device close. We can't >>>>> defer it into some background operation like pm. >>>> >>>> Yeah, but you only need that in a couple of use cases and not all. >>> >>> Not all, that is why the dma_buf_attach_revocable() is there to >>> distinguish this case from others. >> >> No, no that's not what I mean. >> >> See on the one hand you have runtime PM which automatically shuts >> down your device after some time when the last user stops using it. >> >> Then on the other hand you have an intentional revoke triggered by >> userspace. >> >> As far as I've read up on the code currently both are handled the >> same way, and that doesn't sound correct to me. >> >> Runtime PM should *not* trigger automatically when there are still >> mappings or even DMA-bufs in existence for the VFIO device. > > I'm a little confused why we are talking about runtime PM - are you > pointing out an issue in VFIO today where it's PM support is not good?
Exactly that, yes. This patch set here doesn't break it, but most likely makes the effect quite worse. > 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. Regards, Christian. > Jason
