Re: [PATCH v4 2/4] vfio/pci: Add an error handler callback

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

On 9/2/2026 1:07 AM, Cédric Le Goater wrote:
> +Shameer, who is looking at forwarding AER errors to guest :
>
> https://lore.kernel.org/qemu-devel/SJ0PR12MB8614DDFEE3A9575564EDEF99ABFF2@SJ0PR12MB8614.namprd12.prod.outlook.com/
>
> On 8/31/26 20:31, Farhan Ali wrote:
>> Provide a vfio error handling callback, that can be used by devices to
>> handle PCI errors for passthrough devices.
>>
>> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
>> ---
>>   hw/vfio/pci.c | 27 +++++++++++++++++++++------
>>   hw/vfio/pci.h |  1 +
>>   2 files changed, 22 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>> index 428ab2f069..a2f489b34d 100644
>> --- a/hw/vfio/pci.c
>> +++ b/hw/vfio/pci.c
>> @@ -3244,21 +3244,36 @@ void vfio_pci_put_device(VFIOPCIDevice *vdev)
>>   static void vfio_err_notifier_handler(void *opaque)
>>   {
>>       VFIOPCIDevice *vdev = opaque;
>> +    Error *err = NULL;
>>         if (!event_notifier_test_and_clear(&vdev->err_notifier)) {
>>           return;
>>       }
>>         /*
>> -     * TBD. Retrieve the error details and decide what action
>> -     * needs to be taken. One of the actions could be to pass
>> -     * the error to the guest and have the guest driver recover
>> -     * from the error. This requires that PCIe capabilities be
>> -     * exposed to the guest. For now, we just terminate the
>> +     * We can retrieve the error details and decide what action
>> +     * needs to be taken in err_handler(). One of the actions could
>> +     * be to pass the error to the guest and have the guest driver
>> +     * recover from the error. This requires that PCIe capabilities be
>> +     * exposed to the guest.
>> +     *
>> +     * If err_handler() is not implemented/fails, we just terminate the
>>        * guest to contain the error.
>>        */
>>   -    error_report("%s(%s) Unrecoverable error detected. Please 
>> collect any data possible and then kill the guest", __func__, 
>> vdev->vbasedev.name);
>> +    if (vdev->err_handler && vdev->err_handler(vdev, &err)) {
>> +        return;
>> +    }
>> +
>> +    if (err) {
>> +        error_prepend(&err, "Unrecoverable PCIe error detected for 
>> device %s",
>> +                      vdev->vbasedev.name);
>> +        error_report_err(err);
>> +    } else {
>> +        error_printf("Unrecoverable PCIe error detected for device %s",
>> +                     vdev->vbasedev.name);
>> +    }
>> +    error_printf("Please collect any data possible and then kill the 
>> guest");
>
> how about that instead :
>
>   if (err) {
>       error_report("Unrecoverable PCIe error detected for device %s: %s",
>                    vdev->vbasedev.name, error_get_pretty(err));
>       error_free(err);
>   } else {
>       error_report("Unrecoverable PCIe error detected for device %s",
>                    vdev->vbasedev.name);
>   }
>   error_printf("Please collect any data possible and then kill the 
> guest\n");
>
>>         vm_stop(RUN_STATE_INTERNAL_ERROR);
>>   }
>> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
>> index c9ab949870..c067bbbebc 100644
>> --- a/hw/vfio/pci.h
>> +++ b/hw/vfio/pci.h
>> @@ -146,6 +146,7 @@ struct VFIOPCIDevice {
>>       EventNotifier err_notifier;
>>       EventNotifier req_notifier;
>>       int (*resetfn)(struct VFIOPCIDevice *);
>> +    bool (*err_handler)(struct VFIOPCIDevice *, Error **);
>
> Please add documentation, something like :
>
>   /*
>    * Platform-specific error recovery handler.
>    *
>    * Called when the host reports a PCI error via the VFIO error 
> notifier.
>    * The handler should attempt to recover the device and forward the
>    * error to the guest if the platform supports it.
>    *
>    * @vdev: the VFIO PCI device that triggered the error
>    * @errp: set with the failure reason on false return
>    *
>    * Return true on success, the VM continues running.
>    * Return false on failure and set @errp, the VM will be stopped.
>    */
>   bool (*err_handler)(struct VFIOPCIDevice *vdev, Error **errp);
>
Yup, I can add that.


>
> That said, I'd prefer to see AER forwarding first.

I am curious too to understand how AER forwarding will work. Based on 
qemu patches (which may not be complete) [1], I can't tell how AER or an 
event will be sent to a guest to notify of an error. Based on the 
discussion on the link you posted, it looks like APEI/GHES based events 
would be sent to the guest?

Another question regarding AER recovery series, do we need some 
mechanism to get the AER information from the kernel for userspace? I am 
trying to understand if QEMU has to forward an AER event, does it need 
to get information such status/mask registers etc?


[1] 
https://github.com/shamiali2008/qemu-master/commit/e45458710cd8509fa5bd81f4376126b77b6f40be


>
> Thanks,
>
> C.
>
>
>>       uint32_t vendor_id;
>>       uint32_t device_id;
>>       uint32_t sub_vendor_id;
>