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: 38+ 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-16 9:19 ` Jan Beulich
2013-12-13 16:09 ` Konrad Rzeszutek Wilk
2013-12-13 16:09 ` [RFC PATCH 2/5] xen-pciback: First reset, then free Konrad Rzeszutek Wilk
2013-12-13 16:09 ` Konrad Rzeszutek Wilk
2013-12-16 9:23 ` [Xen-devel] " Jan Beulich
2013-12-16 9:23 ` 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 ` Jan Beulich
2013-12-16 9:27 ` [Xen-devel] " Jan Beulich
2013-12-13 16:09 ` Konrad Rzeszutek Wilk
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-16 9:28 ` Jan Beulich
2013-12-13 16:09 ` Konrad Rzeszutek Wilk
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-13 16:18 ` Konrad Rzeszutek Wilk
2013-12-16 11:34 ` David Vrabel
2013-12-16 11:34 ` [Xen-devel] " David Vrabel
2013-12-16 14:39 ` Konrad Rzeszutek Wilk [this message]
2013-12-16 14:39 ` Konrad Rzeszutek Wilk
2013-12-13 16:09 ` Konrad Rzeszutek Wilk
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:23 ` [Xen-devel] " Sander Eikelenboom
2013-12-16 15:36 ` Konrad Rzeszutek Wilk
2013-12-16 15:45 ` Sander Eikelenboom
2013-12-16 15:45 ` [Xen-devel] " Sander Eikelenboom
2013-12-16 22:51 ` Sander Eikelenboom
2013-12-16 22:51 ` Sander Eikelenboom
2013-12-16 15:36 ` Konrad Rzeszutek Wilk
2013-12-16 14:35 ` Konrad Rzeszutek Wilk
2013-12-16 10:59 ` David Vrabel
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.