From: David Vrabel <david.vrabel@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 11:34:32 +0000 [thread overview]
Message-ID: <52AEE548.8010800@citrix.com> (raw)
In-Reply-To: <1386950978-8628-6-git-send-email-konrad.wilk@oracle.com>
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?
> --- 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;
}
It is safe to reset unbound devices (even if they're not (or intended)
to be available to pciback).
It is also possible in the above loop if slot reset is supported to
ignore sibling devices that are on different slots.
> + 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.
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 11:34 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 ` David Vrabel [this message]
2013-12-16 14:39 ` [Xen-devel] " 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: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=52AEE548.8010800@citrix.com \
--to=david.vrabel@citrix.com \
--cc=gordan@bobich.net \
--cc=konrad.wilk@oracle.com \
--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