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

[Farhan Ali <alifm@linux.ibm.com>]

On 6/3/2026 3:46 PM, Alex Williamson wrote:
> On Wed,  3 Jun 2026 11:24:14 -0700
> Farhan Ali <alifm@linux.ibm.com> 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@linux.ibm.com>
>> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
>> Acked-by: Alex Williamson <alex@shazbot.org>
>> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
>> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
>> ---
>>   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@linux.ibm.com
>
> 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