From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932429AbcK1J27 (ORCPT ); Mon, 28 Nov 2016 04:28:59 -0500 Received: from cn.fujitsu.com ([59.151.112.132]:43293 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752805AbcK1J2v (ORCPT ); Mon, 28 Nov 2016 04:28:51 -0500 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="13373542" Subject: Re: [PATCH] vfio/pci: Support error recovery To: "Michael S. Tsirkin" References: <1480246457-10368-1-git-send-email-caoj.fnst@cn.fujitsu.com> <20161128045506-mutt-send-email-mst@kernel.org> CC: , , , From: Cao jin Message-ID: <583BF99F.9030106@cn.fujitsu.com> Date: Mon, 28 Nov 2016 17:32:15 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20161128045506-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.69] X-yoursite-MailScanner-ID: E8F2D47AC8B5.A946A X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: caoj.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?) >> 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) >> + 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? -- Sincerely, Cao jin