From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
gordan@bobich.net
Subject: Re: [Xen-devel] [RFC PATCH 5/5] xen/pciback: PCI reset slot or bus
Date: Mon, 16 Dec 2013 09:39:16 -0500 [thread overview]
Message-ID: <20131216143916.GC12913@phenom.dumpdata.com> (raw)
In-Reply-To: <52AEE548.8010800@citrix.com>
On Mon, Dec 16, 2013 at 11:34:32AM +0000, David Vrabel wrote:
> On 13/12/13 16:09, Konrad Rzeszutek Wilk wrote:
> > The life-cycle of a PCI device in Xen pciback is a bit complex.
> >
> > It starts with the device being binded to us - for which
> > we do a device function reset.
> >
> > If the device is unbinded from us - we also do a function
> > reset.
>
> Spelling: bound and unbound.
>
> > The reset is done when all of the functions of a device
> > are binded to Xen pciback. Or when a device is un-assigned
> > from a guest. We do this by having a 'completion' workqueue
> > on which the users of the PCI device wait. This workqueue
> > is started once the device has been 'binded' or de-assigned
> > from a guest.
>
> The use of a work item and a completion baffles me. What problem does
> this solve?
Avoiding of deadlock. Whenever you do any SysFS operations on on PCI
devices it ends up locking pci_dev and then we try to use it .. and
end up dead-locking. I should have clarified that more.
I could add code to pci (Generic) to have an non-locking variant - but
there is soo much of it I think doing it in a work item and completion
would be much simpler.
>
> > --- a/drivers/xen/xen-pciback/pci_stub.c
> > +++ b/drivers/xen/xen-pciback/pci_stub.c
> [...]
> > + /* We expect X amount of slots (this would also find out
> > + * if we do not have all of the slots assigned to us).
> > + */
> > + list_for_each_entry(pci_dev, &dev->bus->devices, bus_list)
> > + slots++;
> > +
> > + spin_lock_irqsave(&pcistub_devices_lock, flags);
> > + /* Iterate over the existing devices to ascertain whether
> > + * all of them are under the bridge and not in use. */
> > + list_for_each_entry(psdev, &pcistub_devices, dev_list) {
> > + if (!psdev->dev)
> > + continue;
> > +
> > + if (pci_domain_nr(psdev->dev->bus) == pci_domain_nr(dev->bus) &&
> > + psdev->dev->bus->number == dev->bus->number &&
> > + PCI_SLOT(psdev->dev->devfn) == PCI_SLOT(dev->devfn)) {
> > + slots--;
> > + /* Ignore ourselves in case hadn't cleaned up yet */
> > + if (psdev->pdev && psdev->dev != dev)
> > + inuse++;
> > + }
> > + }
>
> This check looks broken. A device added to pciback but still bound to
> another driver will be considered as safe to reset.
>
> I think you want something like:
>
> list_for_each_entry(pdev, &dev->bus->devices, bus_list)
> {
> if (pdev != dev && pdev->driver
> && pdev->driver != xen_pcibk_pci_driver))
> return -ENOTTY;
> }
Good catch!
>
> It is safe to reset unbound devices (even if they're not (or intended)
> to be available to pciback).
OK, we can check for that.
>
> It is also possible in the above loop if slot reset is supported to
> ignore sibling devices that are on different slots.
Not sure what you mean?
>
> > + spin_unlock_irqrestore(&pcistub_devices_lock, flags);
> > + /* Slots should be zero (all slots under the bridge are
> > + * accounted for), and inuse should be zero (not assigned
> > + * to anybody). */
> > + if (!slots && !inuse) {
> > + int rc = 0, bus = 0;
> > + list_for_each_entry(pci_dev, &dev->bus->devices, bus_list) {
> > + dev_dbg(&pci_dev->dev, "resetting the slot device\n");
> > + if (!pci_probe_reset_slot(pci_dev->slot))
> > + rc = pci_reset_slot(pci_dev->slot);
> > + else
> > + bus = 1;
> > + if (rc)
> > + dev_info(&pci_dev->dev, "resetting slot failed with %d\n", rc);
> > + }
>
> Why are you resetting every slot on the bus? You only need to reset the
> slot that the device is on.
Bug.
>
> Take a look at the vfio-pci driver. It does this bus/slot reset choice
> in a much more straightforward way.
>
> David
next prev parent reply other threads:[~2013-12-16 14:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 16:09 [RFC PATCH] Xen PCI back - do slot and bus reset (v0) Konrad Rzeszutek Wilk
2013-12-13 16:09 ` [RFC PATCH 1/5] xen-pciback: Cleanup up pcistub_put_pci_dev Konrad Rzeszutek Wilk
2013-12-16 9:19 ` [Xen-devel] " Jan Beulich
2013-12-13 16:09 ` [RFC PATCH 2/5] xen-pciback: First reset, then free Konrad Rzeszutek Wilk
2013-12-16 9:23 ` [Xen-devel] " Jan Beulich
2013-12-13 16:09 ` [RFC PATCH 3/5] xen-pciback: Document when we FLR an PCI device Konrad Rzeszutek Wilk
2013-12-16 9:27 ` [Xen-devel] " Jan Beulich
2013-12-13 16:09 ` [RFC PATCH 4/5] xen/pciback: Move the FLR code to a function Konrad Rzeszutek Wilk
2013-12-16 9:28 ` [Xen-devel] " Jan Beulich
2013-12-13 16:09 ` [RFC PATCH 5/5] xen/pciback: PCI reset slot or bus Konrad Rzeszutek Wilk
2013-12-13 16:18 ` Konrad Rzeszutek Wilk
2013-12-16 11:34 ` [Xen-devel] " David Vrabel
2013-12-16 14:39 ` Konrad Rzeszutek Wilk [this message]
2013-12-13 16:52 ` [RFC PATCH] Xen PCI back - do slot and bus reset (v0) Gordan Bobic
2013-12-16 10:59 ` [Xen-devel] " David Vrabel
2013-12-16 14:35 ` Konrad Rzeszutek Wilk
2013-12-16 15:23 ` Sander Eikelenboom
2013-12-16 15:36 ` Konrad Rzeszutek Wilk
2013-12-16 15:45 ` Sander Eikelenboom
2013-12-16 22:51 ` Sander Eikelenboom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131216143916.GC12913@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=gordan@bobich.net \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox