RE: [RFC PATCH v2 00/16] vfio/pci: Handle PCI error recovery and report state to userspace

[Shameer Kolothum Thodi]

> -----Original Message-----
> From: Keith Busch <kbusch@xxxxxxxxxx>
> Sent: 06 November 2026 16:57
> To: Shameer Kolothum Thodi <skolothumtho@xxxxxxxxxx>
> Cc: kvm@xxxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; alex@xxxxxxxxxxx; jgg@xxxxxxxx;
> kevin.tian@xxxxxxxxx; kbusch@xxxxxxxx; michal.winiarski@xxxxxxxxx;
> satyanarayana.k.v.p@xxxxxxxxx; Sonang Patel <sonangp@xxxxxxxxxx>; Ankit
> Agrawal <ankita@xxxxxxxxxx>; Nathan Chen <nathanc@xxxxxxxxxx>; Matt
> Ochs <mochs@xxxxxxxxxx>
> Subject: Re: [RFC PATCH v2 00/16] vfio/pci: Handle PCI error recovery and
> report state to userspace
> 
> External email: Use caution opening links or attachments
> 
> 
> On Tue, Sep 29, 2026 at 06:32:49PM +0100, Shameer Kolothum wrote:
> > Hi,
> >
> > Currently, vfio-pci signals the error eventfd from error_detected() and
> > returns PCI_ERS_RESULT_CAN_RECOVER, including for permanent failure. It
> > has no slot_reset() or resume() callback, so userspace is not notified
> > when host recovery completes or whether the device was reset.
> >
> > This series adds opt-in host PCI error recovery for vfio-pci. It blocks
> > device access during recovery, restores device state after a host reset,
> > and reports recovery status to userspace. The kernel runs host recovery
> > and the VMM decides how to recover the guest.
> 
> We've been experiementating with this recently. It turns out that doing
> a meaningful recovery on the user space side is a bit more difficult
> than initially thought, but we can at least get more deterministic
> behavior with these notifications and gracefully stop affected
> processes. I don't think there is much else the kernel side can do to
> make this go any better, so this series looks good to us.
> 
> Acked-by: Keith Busch <kbusch@xxxxxxxxxx>

Hi Keith,

Thanks for that. I have posted an RFC v3 here [0]. The overall design
and UAPI remain the same, but access serialization and power-state
locking have changed enough that I haven't carried your Acked-by 
forward.

Please take a look at v3 and let me know whether your ack still
applies.

Thanks,
Shameer

[0] https://lore.kernel.org/kvm/20261112141632.918954-1-skolothumtho@xxxxxxxxxx/