From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] xen/pci: Deal with toolstack missing an 'XenbusStateClosing'. Date: Tue, 11 Jun 2013 16:36:10 +0100 Message-ID: <51B743EA.5020800@eu.citrix.com> References: <20130610202456.GA17822@phenom.dumpdata.com> <1370898399-20968-1-git-send-email-konrad.wilk@oracle.com> <1370898399-20968-2-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1370898399-20968-2-git-send-email-konrad.wilk@oracle.com> Sender: stable-owner@vger.kernel.org To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Bjorn Helgaas , linux-pci@vger.kernel.org, stable@vger.kernel.org List-Id: xen-devel@lists.xenproject.org On 06/10/2013 10:06 PM, Konrad Rzeszutek Wilk wrote: > 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 > )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. So I looked a little bit into this; there are actually two different states that happen as part of this handshake. In order to disonnect a *device*, xl signals using the *bus* state, like this: * Wait for the *bus* to be in state 4(Connected) * Set the *device* state to 5(Closing) * Set the *bus* state to 7(Reconfiguring) * Wait for the *bus* state to return to 4(Connected) So are all of these states you see the *bus* state? And why would you disconnect the whole pci bus if you're only removing one device? -George