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.
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.
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?
Thanks
Farhan
Thanks,
Shameer
