Jan Beulich writes ("libxl / xen-pciback interaction"):
> while trying to test a pciback fix for how SR-IOV VFs get placed in the
> guest PCI topology I noticed that my test VM would only ever see the 1st
> out of 3 VFs that I passed to it. As it turns out, the driver watches
> its own (backend) node, and upon first receiving notification it
> evaluates state found in xenstore to set up the backend device.
> Subsequently it switches the device to Initialised. After this switching,
> not further instances of the watch triggering would do anything.This makes it sound like this driver does not support hotplug. > While doing this it also occurred to me as odd how "num_devs" is > actually used: It's not really a "number of devices" indicator, but > instead a "next device has this number" one: libxl reads the present > value and increments it by one for every new device. Destroying > (hot-unplugging) of devices doesn't have any effect on the value. But this makes it sound like the driver *does* support hotplug. How does what libxl is doing differ from a setup, immediately followed by a hot-add ? > If addition / removal of a device happens a number of times for a > VM, quite a few leftover, no longer used entries would accumulate > afaict. This isn't only consuming space in xenstore for no good > reason, but also means pciback has to do an increasing amount of > processing every time a reconfigure event happens. I'm kind of surprised that num_devs is used this way by the driver. I guess the obvious approach of just listing the directory to find the devices would often be accidentally-quadratic in the number of simultaneous PCI devices but that hardly seems like a problem. I wonder if there is some race/reuse hazard that would prevent libxl knowing when to reuse a dev number. Ian.
