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
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
