Re: [libvirt] mdevctl: A shoestring mediated device management and persistence utility

On Tue, 11 Jun 2019 21:45:08 +0200 Cornelia Huck <cohuck(a)redhat.com&gt; wrote: > On Fri, 7 Jun 2019 18:06:30 +0200 > Halil Pasic <pasic(a)linux.ibm.com&gt; wrote:

> > I guess for vfio-ccw one needs to make sure that the ccw device is bound > > to the vfio-ccw driver first, and only after that can one use > > create-mdev to create the mdev on top of the subchannel. > > > > So to make this work persistently (survive a reboot) one would need to > > take care of the subchannel getting bound to the right vfio_ccw driver > > before mdevctl is called. Right? > > > > BTW how does this concurrence situation between the drivers io_subchannel > > and vfio_ccw work? Especially if both are build in? > > If you have two drivers that match to the same device type, you'll > always have the issue that the driver that is first matched with the > device will bind to it and you have to do the unbind/rebind dance to > get it bound to the correct device driver. (I guess that this was the > basic motivation behind the ap bus default driver infrastructure, > right?) I think that in our case the io_subchannel driver will be > called first (alphabetical order and the fact that vfio-ccw will often > be a module). I'm not sure if it is within the scope of mdevctl to > ensure that the device is bound to the correct driver, or if it rather > should work with devices already bound to the correct driver only. > Maybe a separate udev-rules generator? Getting a device bound to a specific driver is exactly the domain of driverctl. Implement the sysfs interfaces driverctl uses and see if it works. Driverctl defaults to PCI and knows some extra things about PCI, but appears to be written to be generally bus agnostic. Thanks, Alex