On Wed, Nov 30, 2016 at 09:04:13PM -0700, Alex Williamson wrote:
> On Sun, 27 Nov 2016 19:34:17 +0800
> Cao jin <caoj.fnst@xxxxxxxxxxxxxx> wrote:
>
> > It is user space driver's or device-specific driver's(in guest) responsbility
> > to do a serious recovery when error happened. Link-reset is one part of
> > recovery, when pci device is assigned to VM via vfio, link-reset will do
> > twice in host & guest separately, which will cause many trouble for a
> > successful recovery, so, disable the vfio-pci's link-reset in aer driver
> > in host, this is a keypoint for guest to do error recovery successfully.
> >
> > CC: alex.williamson@xxxxxxxxxx
> > CC: mst@xxxxxxxxxx
> > Signed-off-by: Cao jin <caoj.fnst@xxxxxxxxxxxxxx>
> > ---
> > This is actually a RFC version(has debug lines left), and has minor changes in
> > aer driver, so I think maybe it is better not to CC pci guys in this round.
> > Later will do.
> >
> > drivers/pci/pcie/aer/aerdrv_core.c | 12 ++++++-
> > drivers/vfio/pci/vfio_pci.c | 63 +++++++++++++++++++++++++++++++++++--
> > drivers/vfio/pci/vfio_pci_private.h | 2 ++
> > 3 files changed, 74 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c
> > index 521e39c..289fb8e 100644
> > --- a/drivers/pci/pcie/aer/aerdrv_core.c
> > +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> > @@ -496,7 +496,17 @@ static void do_recovery(struct pci_dev *dev, int severity)
> > "error_detected",
> > report_error_detected);
> >
> > - if (severity == AER_FATAL) {
> > + /* vfio-pci as a general meta driver, it actually couldn't do any real
> > + * recovery for device. It is user space driver, or device-specific
> > + * driver in guest who should take care of the serious error recovery,
> > + * link reset actually is one part of whole recovery. Doing reset_link
> > + * in aer driver of host kernel for vfio-pci devices will cause many
> > + * trouble for user space driver or guest's device-specific driver,
> > + * for example: the serious recovery often need to read register in
> > + * config space, but if register reading happens during link-resetting,
> > + * it is quite possible to return invalid value like all F's, which
> > + * will result in unpredictable error. */
> > + if (severity == AER_FATAL && strcmp(dev->driver->name, "vfio-pci")) {
> > result = reset_link(dev);
> > if (result != PCI_ERS_RESULT_RECOVERED)
> > goto failed;
>
> This is not acceptable. If we want to make a path through AER recovery
> that does not reset the link, there should be a way for the driver to
> request it. Testing the driver name is a horrible hack.
Right, just set a flag or something.
> The other
> question is what guarantees does vfio make that the device does get
> reset? If an AER fault occurs and the user doesn't do a reset, what
> happens when that device is released and a host driver tries to make
> use of it? The user makes no commitment to do a reset and there are
> only limited configurations where we even allow the user to perform a
> reset.
Let's try to work out what can be done a bit more constructively.
Doesn't vfio already reset device on release?
How about detecting there was an unhandled AER event
and doing link reset at that point?
> > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> > index 712a849..aefd751 100644
> > --- a/drivers/vfio/pci/vfio_pci.c
> > +++ b/drivers/vfio/pci/vfio_pci.c
> > @@ -535,6 +535,15 @@ static long vfio_pci_ioctl(void *device_data,
> > struct vfio_pci_device *vdev = device_data;
> > unsigned long minsz;
> >
> > + if (vdev->aer_recovering && (cmd == VFIO_DEVICE_SET_IRQS ||
> > + cmd == VFIO_DEVICE_RESET || cmd == VFIO_DEVICE_PCI_HOT_RESET)) {
> > + int ret;
> > + ret = wait_for_completion_interruptible(
> > + &vdev->aer_error_completion);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > if (cmd == VFIO_DEVICE_GET_INFO) {
> > struct vfio_device_info info;
> >
> > @@ -1117,6 +1126,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > vdev->irq_type = VFIO_PCI_NUM_IRQS;
> > mutex_init(&vdev->igate);
> > spin_lock_init(&vdev->irqlock);
> > + init_completion(&vdev->aer_error_completion);
> >
> > ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
> > if (ret) {
> > @@ -1176,6 +1186,9 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct pci_dev *pdev,
> > {
> > struct vfio_pci_device *vdev;
> > struct vfio_device *device;
> > + u32 uncor_status = 0;
> > + unsigned int aer_cap_offset = 0;
>
> Unnecessary initialization.
>
> > + int ret;
> >
> > device = vfio_device_get_from_dev(&pdev->dev);
> > if (device == NULL)
> > @@ -1187,10 +1200,30 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct pci_dev *pdev,
> > return PCI_ERS_RESULT_DISCONNECT;
> > }
> >
> > + /* get device's uncorrectable error status as soon as possible,
> > + * and signal it to user space. The later we read it, the possibility
> > + * the register value is mangled grows. */
>
> Bad comment style (throughout).
>
> > + aer_cap_offset = pci_find_ext_capability(vdev->pdev, PCI_EXT_CAP_ID_ERR);
> > + ret = pci_read_config_dword(vdev->pdev, aer_cap_offset +
> > + PCI_ERR_UNCOR_STATUS, &uncor_status);
> > + if (ret)
> > + return PCI_ERS_RESULT_DISCONNECT;
> > +
> > + pr_err("device %d got AER detect notification. uncorrectable error status = 0x%x\n", pdev->devfn, uncor_status);//to be removed
> > mutex_lock(&vdev->igate);
> > +
> > + vdev->aer_recovering = true;
> > + reinit_completion(&vdev->aer_error_completion);
> > +
> > + /* suspend config space access from user space,
> > + * when vfio-pci's error recovery process is on */
> > + pci_cfg_access_trylock(vdev->pdev);
> >
> > - if (vdev->err_trigger)
> > - eventfd_signal(vdev->err_trigger, 1);
> > + if (vdev->err_trigger && uncor_status) {
> > + pr_err("device %d signal uncor status to user space", pdev->devfn);//may be removed
> > + /* signal uncorrectable error status to user space */
> > + eventfd_signal(vdev->err_trigger, uncor_status);
What does this mean that we trigger with uncor_status as opposed to 1?
> > + }
>
> } else... what? By bypassing the AER link reset we've assumed
> responsibility for resetting the device. Even if we signal the user,
> what guarantee do we have that the device is recovered?
So set flag and recover ?
> >
> > mutex_unlock(&vdev->igate);
> >
> > @@ -1199,8 +1232,34 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct pci_dev *pdev,
> > return PCI_ERS_RESULT_CAN_RECOVER;
> > }
> >
> > +static void vfio_pci_aer_resume(struct pci_dev *pdev)
> > +{
> > + struct vfio_pci_device *vdev;
> > + struct vfio_device *device;
> > +
> > + device = vfio_device_get_from_dev(&pdev->dev);
> > + if (device == NULL)
> > + return;
> > +
> > + vdev = vfio_device_data(device);
> > + if (vdev == NULL) {
> > + vfio_device_put(device);
> > + return;
> > + }
> > +
> > + /* vfio-pci's error recovery is done, time to
> > + * resume pci config space's accesses */
> > + pci_cfg_access_unlock(vdev->pdev);
> > +
> > + vdev->aer_recovering = false;
> > + complete_all(&vdev->aer_error_completion);
> > +
> > + vfio_device_put(device);
> > +}
> > +
> > static const struct pci_error_handlers vfio_err_handlers = {
> > .error_detected = vfio_pci_aer_err_detected,
> > + .resume = vfio_pci_aer_resume,
> > };
> >
> > static struct pci_driver vfio_pci_driver = {
> > diff --git a/drivers/vfio/pci/vfio_pci_private.h b/drivers/vfio/pci/vfio_pci_private.h
> > index 8a7d546..ebf1041 100644
> > --- a/drivers/vfio/pci/vfio_pci_private.h
> > +++ b/drivers/vfio/pci/vfio_pci_private.h
> > @@ -83,6 +83,8 @@ struct vfio_pci_device {
> > bool bardirty;
> > bool has_vga;
> > bool needs_reset;
> > + bool aer_recovering;
> > + struct completion aer_error_completion;
> > struct pci_saved_state *pci_saved_state;
> > int refcnt;
> > struct eventfd_ctx *err_trigger;
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
