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

[Matt Evans]

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.


M