Hi Farhan, > -----Original Message----- > From: Farhan Ali <[email protected]> > Sent: 03 September 2026 19:07 > To: Shameer Kolothum Thodi <[email protected]>; Cédric Le Goater > <[email protected]>; [email protected]; [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [PATCH v4 2/4] vfio/pci: Add an error handler callback > > External email: Use caution opening links or attachments > > > Hi Shameer, > > Thanks for your response! > > On 9/3/2026 5:08 AM, Shameer Kolothum Thodi wrote: > >>> 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? > > Right, that QEMU branch is an early prototype which only observes and > > logs, so the forwarding is not in it. > > > > I am working on a QEMU branch which adds it, based on the kernel RFC. > > The plan is to use native AER rather than GHES, so QEMU injects with > > pcie_aer_inject_error() and an emulated pcie-root-port raises the > > interrupt to the guest. I will post a link once it is ready. > > I am very curious to know (and learn) how we would do this.
I have a branch that does the AER error injection into the guest here: https://github.com/shamiali2008/qemu-master/commits/private-master-vfio-aer-test-v2/ Note: This is only for RFC test purposes. > > > >> Another question regarding AER recovery series, do we need some > >> mechanism to get the AER information from the kernel for userspace? > > Not as it stands. The feature reports how severe the event was and > > what the host did, not which error occurred, so QEMU cannot forward > > the real status bits today. If it is something that is useful then it > > probably needs to be added > > IMHO I think there might be value in providing more detailed information to > the QEMU/guest. Ok. I will have a look and see how we can propagate that into userspace. > > Based on my brief look at the kernel/QEMU patch series, it looks like there is > not much coordination between the guest and host recovery. So when we > inject an AER in the guest, is the device access still blocked? > Is the device access enabled only after a guest completed the recovery? Access is already unblocked when the guest sees the error. QEMU injects the error only after host recovery has finished, so the guest driver runs against a device it can read. You are right that there is no coordination between guest and host and that is deliberate. Please see Alex's reply here on which the RFC design is based: https://lore.kernel.org/qemu-devel/[email protected]/ The cost is that the guest only recovers once the host has finished, and cannot influence what the host does. If the guest driver wants a reset it will do one, on a device the host has already reset. Thanks, Shameer
