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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

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 :-)



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