Re: [PATCH v3 6/9] vfio/pci: Clean up BAR zap and revocation

[Alex Williamson]

On Fri, 19 Jun 2026 16:13:17 +0100
Matt Evans <matt@xxxxxxxxxx> wrote:

> Hi Jason,
> 
> On 19/06/2026 14:31, Jason Gunthorpe wrote:
> > On Thu, Jun 18, 2026 at 05:02:58PM +0100, Matt Evans wrote:
> >   
> >> My understanding is that the sequences above wake a device that happens
> >> to have previously been put into D3, and AFAICT it could only have got
> >> there because of a previous vfio_pci_set_power_state().  Seems its only
> >> caller is from the emulation of PCI_PM_CTRL using
> >> vfio_lock_and_set_power_state(), and this zaps/revokes BAR access before
> >> a transition to D3.  Similarly, an attempt to access a BAR via an
> >> ioctl/through vfio_pci_core_do_io_rw() fails the D3 check in
> >> __vfio_pci_memory_enabled(), and besides will try to take the memory_lock.  
> > 
> > I thought the general design was the bars were made inaccessible
> > before going to a low power state, and remain inaccessible while it is
> > in low power?
> > 
> > So the order of D0 doesn't matter. If it is not in D0 then there is no
> > mappings and zap/revoke is a NOP.
> > 
> > If is it in D0 then it doesn't matter because D0 is a nop.  
> Yes, that's what I'm getting at. :)  If it's in D3 then BARs are
> inaccessible, so as long as we go into D0 before the DMABUF move, the
> order of the zap relative to the "go to D0" doesn't matter.

I believe this is correct as well, but importantly we cannot assume
that a stray read or write just returns -1 or gets dropped.  This is
exactly why we have such hard protections against the user accessing
the device while it's disabled.  Not all platforms, even within
architectures that might otherwise be considered lenient of such
accesses, consider this benign and might escalate to system level
faults.

Let's be careful not to frame this as "the access doesn't matter
anyway", the answer is instead that non-D0 devices already lack any
mappings to access the device.  Thanks,

Alex