[Xen-changelog] [linux-2.6.18-xen] pcifront: Deal with toolstack missing 'XenbusStateClosing' state.

[Xen patchbot-linux-2.6.18-xen <patchbot@xxxxxxx>]

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
# Date 1382348852 -7200
# Node ID 2427f3a0bac88b02829e4c3d75a349c596fa0dd7
# Parent  3ae180dda3a99b5208e13083a3767c041632363b
pcifront: Deal with toolstack missing 'XenbusStateClosing' state.

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 single 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 back 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]

Note that this is for a _single_ PCI device. If there were two
PCI devices and only one was disconnected 'xm' would show the same
state changes.

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 (for one or more
PCI devices) and with 'xm' toolstack (for more than two PCI
devices).

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

While I continue to think this ought to be fixed in xl, consensus seems
to be that the frontend should be able to cope with this.

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
Committed-by: Jan Beulich <jbeulich@xxxxxxxx>
---


diff -r 3ae180dda3a9 -r 2427f3a0bac8 drivers/xen/pcifront/pci.c
--- a/drivers/xen/pcifront/pci.c        Wed Oct 16 15:07:28 2013 +0200
+++ b/drivers/xen/pcifront/pci.c        Mon Oct 21 11:47:32 2013 +0200
@@ -22,10 +22,8 @@ int pcifront_connect(struct 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");
-               err = -EEXIST;
-       }
+       else
+               dev_info(&pdev->xdev->dev, "PCI frontend already installed\n");
 
        spin_unlock(&pcifront_dev_lock);
 

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog