Re: [PATCH v18 3/4] vfio/pci: Add a reset_done callback for vfio-pci driver

[Farhan Ali]

On 6/3/2026 3:46 PM, Alex Williamson wrote:
> On Wed,  3 Jun 2026 11:24:14 -0700
> Farhan Ali <alifm@xxxxxxxxxxxxx> wrote:
>
> > On error recovery for a PCI device bound to vfio-pci driver, we want to
> > recover the state of the device to its last known saved state. The callback
> > restores the state of the device to its initial saved state.
> >
> > Reviewed-by: Julian Ruess <julianr@xxxxxxxxxxxxx>
> > Reviewed-by: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
> > Acked-by: Alex Williamson <alex@xxxxxxxxxxx>
> > Reviewed-by: Matthew Rosato <mjrosato@xxxxxxxxxxxxx>
> > Signed-off-by: Farhan Ali <alifm@xxxxxxxxxxxxx>
> > ---
> >   drivers/vfio/pci/vfio_pci_core.c | 12 ++++++++++++
> >   1 file changed, 12 insertions(+)
> Sashiko has some interesting comments:
>
> https://sashiko.dev/#/patchset/20260603182415.2324-4-alifm@xxxxxxxxxxxxx
>
> I think the critical is a calculated risk we're taking, restoring the
> hand-off state after reset.  I don't think we'd considered the race,
> and it seems the commit log could use some improvement, especially if
> we do need to revisit this based on the calculated risk.  Thanks,
>
> Alex

Regarding the race mentioned by sashiko, pci_load_saved_state() also has 
a check to make sure the state passed is not NULL. However the race 
mentioned by sashiko seems plausible. The reset_done() callback is 
called with pci device lock held, but it might not be enough to protect 
against the race and so we need to grab the dev_set->lock here? For the 
commit message how about adding something like this? "This will 
intentionally reset all the runtime PCI configuration changes such as 
BAR programming and MSI-X enablement"

Thanks

Farhan