linux-kernel - Re: [PATCH] vfio/pci: Support error recovery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161130033533-mutt-send-email-mst@kernel.org>
Date:   Wed, 30 Nov 2016 03:46:52 +0200
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Cao jin <caoj.fnst@...fujitsu.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        izumi.taku@...fujitsu.com, alex.williamson@...hat.com
Subject: Re: [PATCH] vfio/pci: Support error recovery

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@...hat.com
> > > CC: mst@...hat.com
> > > Signed-off-by: Cao jin <caoj.fnst@...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. */
> > 
> > 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
>