Re: libxl / xen-pciback interaction [and 1 more messages]

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

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.