On Sun, 27 Nov 2016 19:34:17 +0800
Cao jin <caoj.f...@cn.fujitsu.com> 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.william...@redhat.com
> CC: m...@redhat.com
> Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com>
> ---
> 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.  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.

> 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);
> +        }

} 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?

>  
>       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;

Reply via email to