Hi Michael, Thanks for the review. I will post a v3 with the following.
On Sun, Aug 02, 2026 at 05:10:21PM -0400, Michael S. Tsirkin wrote: > On Fri, Jul 31, 2026 at 11:17:00AM +0800, Xixin Liu wrote: > > virtio-pci only registered reset_prepare/reset_done. The PCI error > > recovery core treats devices without error_detected as NO_AER_DRIVER and > > does not deliver pci_channel_io_perm_failure to the driver after a failed > > recovery. > > Maybe it should? Agreed that the current PCI core behaviour is awkward for drivers that only wire reset_prepare/reset_done. Without .error_detected the recovery core votes NO_AER_DRIVER on the first broadcast, and report_perm_failure_detected skips the driver callback whenever overall status is not RECOVERED. That skip covers NO_AER_DRIVER even when subordinate reset succeeded. uevent DISCONNECT is still emitted. Changing the core would be a PCI-wide policy change. This series registers .error_detected and joins the existing ERS contract the same way other ERS-aware drivers do. Happy to follow up on the PCI side if that is preferred. > > + * permanent failure break virtqueues (follow-up may call driver > > + * .shutdown for block teardown). > > block specifically? this is common code. Right, that wording was wrong for virtio-pci. On perm_failure the common path only calls virtio_break_device() and returns DISCONNECT. Same for every virtio device. > > + return PCI_ERS_RESULT_NEED_RESET; > > so I guess pci will do slot reset? but what will call driver reset > later? confused. NEED_RESET asks for a PCI bus or slot reset. On AER that is aer_root_reset() then pci_bus_error_reset(). That path does not call .reset_prepare or .reset_done; those hooks still serve FLR. Driver restore after a successful reset is .slot_reset. v3 adds that hook and it restores config then calls virtio_device_reset_done(). Quiesce stays in error_detected on frozen via virtio_device_reset_prepare(). If the PCI reset fails, .slot_reset is skipped and perm_failure only breaks the device. > > + default: > > + break; > > + } > > + return PCI_ERS_RESULT_NEED_RESET; > > here, too, and we didn't virtio_device_reset_prepare either. Right. pci_channel_state_t today is only normal, frozen, and perm_failure. In v3 frozen and default share one path: quiesce via virtio_device_reset_prepare(), then NEED_RESET. Thanks, Xixin
