From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756159AbcK3BrC (ORCPT ); Tue, 29 Nov 2016 20:47:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43958 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750708AbcK3Bqy (ORCPT ); Tue, 29 Nov 2016 20:46:54 -0500 Date: Wed, 30 Nov 2016 03:46:52 +0200 From: "Michael S. Tsirkin" To: Cao jin Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, izumi.taku@jp.fujitsu.com, alex.williamson@redhat.com Subject: Re: [PATCH] vfio/pci: Support error recovery Message-ID: <20161130033533-mutt-send-email-mst@kernel.org> References: <1480246457-10368-1-git-send-email-caoj.fnst@cn.fujitsu.com> <20161128045506-mutt-send-email-mst@kernel.org> <583BF99F.9030106@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <583BF99F.9030106@cn.fujitsu.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 30 Nov 2016 01:46:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 28, 2016 at 05:32:15PM +0800, Cao jin wrote: > > > On 11/28/2016 11:00 AM, Michael S. Tsirkin wrote: > > On Sun, Nov 27, 2016 at 07:34:17PM +0800, Cao jin 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@redhat.com > > > CC: mst@redhat.com > > > Signed-off-by: Cao jin > > > --- > > > 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. */ > > > > Fix multi-comment style please. > > > > > + if (severity == AER_FATAL && strcmp(dev->driver->name, "vfio-pci")) { > > > > You really want some flag in the device, or something similar. > > Also, how do we know driver is not going away at this point? > > > > I didn't think of this condition, and I don't quite follow how would driver > go away?(device has error happened, then is removed?) Yes - hotplug request detected. Does something prevent this? > > > result = reset_link(dev); > > > if (result != PCI_ERS_RESULT_RECOVERED) > > > goto failed; > > > > @@ -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. */ > > > + 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 */ > > > > what about access to memory etc? Do you need to suspend this as well? > > > > Yes, this question came into my mind a little bit, but I didn't see some > existing APIs like pci_cfg_access_xxx which can help to do this.(I am still > not familiar with kernel) This isn't easy to do at all. > > > + pci_cfg_access_trylock(vdev->pdev); > > > > If you trylock, you need to handle failure. > > try lock returns 0 if access is already locked, 1 otherwise. Is it necessary > to check its return value? Locked by whom? You blissfully access as if it's locked by you. > > -- > Sincerely, > Cao jin >