[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC v11 3/4] vfio-pci: pass the aer error to gue
From: |
Tian, Kevin |
Subject: |
Re: [Qemu-devel] [PATCH RFC v11 3/4] vfio-pci: pass the aer error to guest |
Date: |
Sun, 22 Jan 2017 04:43:39 +0000 |
> From: Alex Williamson [mailto:address@hidden
> Sent: Saturday, January 21, 2017 2:21 AM
>
> On Fri, 20 Jan 2017 06:57:22 +0000
> "Tian, Kevin" <address@hidden> wrote:
>
> > > From: Alex Williamson
> > > Sent: Thursday, January 19, 2017 6:32 AM
> > >
> > > On Sat, 31 Dec 2016 17:13:07 +0800
> > > Cao jin <address@hidden> wrote:
> > >
> > > > From: Chen Fan <address@hidden>
> > > >
> > > > When physical device has uncorrectable error hanppened, the vfio_pci
> > > > driver will signal the uncorrectable error status register value to
> > > > corresponding QEMU's vfio-pci device via the eventfd registered by this
> > > > device, then, the vfio-pci's error eventfd handler will be invoked in
> > > > event loop.
> > > >
> > > > Construct and pass the aer message to root port, root port will trigger
> > > > an
> > > > interrupt to signal guest, then, the guest driver will do the recovery.
> > > >
> > > > Note: Now only support non-fatal error's recovery, fatal error will
> > > > still result in vm stop.
> > >
> > > Please update the entire commit log, don't just add a note that this
> > > now only covers non-fatal errors.
> > >
> >
> > One thing relate to vIOMMU. There is still a TODO task about forwarding
> > IOMMU fault thru VFIO to Qemu, so Qemu vIOMMU has the chance to
> > walk guest remapping structure to emulate virtual IOMMU fault. Likely
> > it also requires eventfd mechanism.
> >
> > Wondering whether making sense to reuse same eventfd for both AER
> > and vIOMMU or using separate eventfd is also fine? Even go with the
> > former option, I don't expect substantial change to this series. Major
> > change is on interface definition - extensible to multiple types of
> > fault/error conditions instead of assuming AER only.
> >
> > Thoughts?
>
> We can't really convey any information through an eventfd, it's just a
> signal, so I don't think we can use the same eventfd for both types of
> errors. Already here we're discussing the idea of using separate
> eventfds for fatal vs non-fatal AERs. IOMMU error processing seems
> like yet another eventfd and likely some region or ioctl mechanism for
> retrieving the error details since the IOMMU hardware is not directly
> accessible. Furthermore, such an event might logically be connected to
> the vfio container rather than the device, so it might not even use the
> same file descriptor. Thanks,
>
Clear enough. Thanks,
Kevin