xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: george.dunlap@eu.citrix.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH] xen/pci: Deal with toolstack missing an 'XenbusStateClosing'.
Date: Mon, 10 Jun 2013 17:06:39 -0400	[thread overview]
Message-ID: <1370898399-20968-2-git-send-email-konrad.wilk@oracle.com> (raw)
In-Reply-To: <1370898399-20968-1-git-send-email-konrad.wilk@oracle.com>

There are two tool-stack that can instruct the Xen PCI frontend
and backend to change states: 'xm' (Python code with a daemon),
and 'xl' (C library - does not keep state changes).

With the 'xm', the path to disconnect a PCI device (xm pci-detach
<guest> <BDF>)is:

4(Connected)->7(Reconfiguring*)-> 8(Reconfigured)-> 4(Connected)->5(Closing*).

The * is for states that the tool-stack sets. For 'xl', it is similar:

4(Connected)->7(Reconfiguring*)-> 8(Reconfigured)-> 4(Connected)

Both of them also tear down the XenBus structure, so the backend
state ends up going in the 3(Initialised) and calls pcifront_xenbus_remove.

When a PCI device is plugged in (xm pci-attach <guest> <BDF>)
both of them follow the same pattern:
2(InitWait*), 3(Initialized*), 4(Connected*)->4(Connected).

[xen-pcifront ignores the 2,3 state changes and only acts when
4 (Connected) has been reached]

The problem is that git commit 3d925320e9e2de162bd138bf97816bda8c3f71be
("xen/pcifront: Use Xen-SWIOTLB when initting if required") introduced
a mechanism to initialize the SWIOTLB when the Xen PCI front moves to
Connected state. It also had some aggressive seatbelt code check that
would warn the user if one tried to change to Connected state without
hitting first the Closing state:

 pcifront pci-0: PCI frontend already installed!

However, that code can be relaxed and we can continue on working
even if the frontend is instructed to be the 'Connected' state with
no devices and then gets tickled to be in 'Connected' state again.

In other words, this 4(Connected)->5(Closing)->4(Connected) state
was expected, while 4(Connected)->.... anything but 5(Closing)->4(Connected)
was not. This patch removes that aggressive check and allows
Xen pcifront to work with the 'xl' toolstack.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/pci/xen-pcifront.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index ac99515..cc46e253 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -675,10 +675,9 @@ static int pcifront_connect_and_init_dma(struct pcifront_device *pdev)
 	if (!pcifront_dev) {
 		dev_info(&pdev->xdev->dev, "Installing PCI frontend\n");
 		pcifront_dev = pdev;
-	} else {
-		dev_err(&pdev->xdev->dev, "PCI frontend already installed!\n");
+	} else
 		err = -EEXIST;
-	}
+
 	spin_unlock(&pcifront_dev_lock);
 
 	if (!err && !swiotlb_nr_tbl()) {
@@ -846,7 +845,7 @@ static int pcifront_try_connect(struct pcifront_device *pdev)
 		goto out;
 
 	err = pcifront_connect_and_init_dma(pdev);
-	if (err) {
+	if (err && err != -EEXIST) {
 		xenbus_dev_fatal(pdev->xdev, err,
 				 "Error setting up PCI Frontend");
 		goto out;
-- 
1.8.1.4

  reply	other threads:[~2013-06-10 21:06 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-07 15:45 xl pci-detach vs xm pci-detach in Xen 4.3 (one works, the other does not) Konrad Rzeszutek Wilk
2013-06-10 11:12 ` George Dunlap
2013-06-10 11:15   ` Processed: " xen
2013-06-10 13:20   ` Konrad Rzeszutek Wilk
2013-06-10 13:28     ` George Dunlap
2013-06-10 13:30       ` Processed: " xen
2013-06-10 20:24       ` Konrad Rzeszutek Wilk
2013-06-10 20:30         ` Processed: " xen
     [not found]           ` <20131104202224.GA18449@phenom.dumpdata.com>
2013-11-04 20:30             ` Processed: " xen
2013-11-04 20:39               ` Wei Liu
2013-11-04 20:45                 ` Processed: " xen
2013-06-10 21:06         ` (unknown), Konrad Rzeszutek Wilk
2013-06-10 21:06           ` Konrad Rzeszutek Wilk [this message]
2013-06-11  7:29             ` [PATCH] xen/pci: Deal with toolstack missing an 'XenbusStateClosing' Jan Beulich
     [not found]             ` <51B6EDDF02000078000DCFB7@nat28.tlf.novell.com>
2013-06-11  9:00               ` George Dunlap
     [not found]               ` <51B6E711.2000001@eu.citrix.com>
2013-06-11 13:03                 ` konrad wilk
2013-06-11 15:36             ` George Dunlap
2013-06-11 16:08               ` konrad wilk
2013-06-11 16:17                 ` George Dunlap
2013-06-11 16:24                   ` konrad wilk
2013-06-12 13:45                   ` Konrad Rzeszutek Wilk
2013-06-12 13:47                     ` George Dunlap
2013-06-12 14:27                       ` Konrad Rzeszutek Wilk
2013-06-12 17:28                     ` Bjorn Helgaas
2013-06-14 16:28                       ` Konrad Rzeszutek Wilk
2013-11-04 20:43                       ` Konrad Rzeszutek Wilk
2013-11-04 20:56                         ` Ben Guthro
     [not found]                           ` <20131104205917.GA18696@phenom.dumpdata.com>
2013-11-04 21:15                             ` Processed: " xen
2013-06-10 13:30     ` Processed: Re: xl pci-detach vs xm pci-detach in Xen 4.3 (one works, the other does not) xen

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=1370898399-20968-2-git-send-email-konrad.wilk@oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=bhelgaas@google.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /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;
as well as URLs for NNTP newsgroup(s).