Re: [Xen-devel] [PATCH] xen/pci: Deal with toolstack missing an 'XenbusStateClosing'.

[konrad wilk <konrad.wilk@xxxxxxxxxx>]

On 6/11/2013 11:36 AM, George Dunlap wrote:
> 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
> > <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.
> 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?
Correct. The stats I enumerated are *bus* states. Not per-device states.
I presume (and I hadn't checked xm) that Xend has some logic to only 
disconnect the bus if all of the PCI devices have been disconnected. In 
'xl' it does not do that.
The testing I did was just with one PCI device.
>  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel