Re: [Xen-devel] [Xen-unstable] XenbusState signaling with regard to pci-detach on HVM guests

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Friday, August 8, 2014, 10:20:31 AM, you wrote:


> Friday, August 8, 2014, 9:09:55 AM, you wrote:

>>>>> On 08.08.14 at 00:04, <linux@xxxxxxxxxxxxxx> wrote:
>>> Here are both a crude patch for xen/libxl and pciback that change the 
>>> signaling 
>>> and now allow the removal of an individual pci device from a HVM guest.
>>> I hope i took the right states based on the descriptions and code i found.
>>> 
>>> What these patches try to do on remove of a pci device (and when everything 
>>> goes well) is:
>>> - after libxl has removed the device from the guest with a qmp command
>>> - let libxl set the pci-device-state to XenbusStateClosing AND 
>>>   set pci-root-state to XenbusStateReconfiguring
>>> - libxl waits for the pci-root-state to change to XenbusStateReconfigured
>>> 
>>> - pciback has a watch on the pci-root-state and removes the device and 
>>> resets in 
>>>   pci config space, after that it sets the pci-device-state to 
>>> XenbusStateClosed AND
>>>   set pci-root-state to XenbusStateReconfigured
>>> 
>>> - libxl now continues from the on XenbusStateReconfigured, cleans up the 
>>> xenstore entries for 
>>>   the device and finally sets pci-root-state back to XenbusStateConnected

>> A fundamental question: Will the changed libxl work with an
>> unchanged pciback no worse than the unchanged libxl does in
>> all possible scenarios? The thing is that extending the required
>> protocol between two components may only be done in a fully
>> backward compatible way.

>> Jan

> That was my concern as well .. although it's already spaghetti ..
> There are already multiple scenario's:

> - pciback has to serve both libxl and xend
> - there are 3 guest types
>         - PV Guests for which pci-front does most of the signaling (and libxl 
> a 
>           small part)
>         - HVM guest with Qemu traditional, libxl does the signaling
>         - HVM guest with Qemu xen, libxl does the signaling       

> There already are discrepancies:
> - with PV guests, the running state for the pci-device-root is 
>   XenbusStateConnected(4), but the 
>   running state for the actual pci-devices is  XenbusStateInitialised(3)
> - with HVM guests, the running state for the pci-device-root differs, and is 
>   XenbusStateInitialised(3)
>   
> Looks clear to me that should have all been XenbusStateConnected(4)

> - On remove at present libxl sets the pci-device-root state to 
>   XenbusStateReconfiguring(7), for both PV guests and HVM guests
> - However at present pciback doesn't seem to reset that back, so it would
>   stay in that state for ever.

> That doesn't seem to be right as well.

> PV-guests seems to shortcut that libxl part, by doing some direct signaling 
> via
> a direct xenbus connect, from pciback/xenbus.c:

> static DEFINE_XENBUS_DRIVER(xen_pcibk, DRV_NAME,
>         .probe                  = xen_pcibk_xenbus_probe,
>         .remove                 = xen_pcibk_xenbus_remove,
>         .otherend_changed       = xen_pcibk_frontend_changed,
> );



> So how feasible is it to keep on trying to work around on things .. when 
> there 
> is that much spaghetti :-)

The only workaroung (without cleaning up and correcting things) that i can see 
is that pciback on every xenstore change to that part of the xenstore-tree, 
checks if what it things is passed through is also still passed through 
according to the xenstore entries, if not .. it removes and resets the device.




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