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

[Cornelia Huck]

On Wed, 12 Jun 2019 17:54:34 +0200
Halil Pasic <pasic at linux.ibm.com> wrote:

> On Wed, 12 Jun 2019 09:14:39 +0200
> Cornelia Huck <cohuck at redhat.com> wrote:

> > Ok, looked at driverctl. Extending this one for non-PCI seems like a
> > reasonable path. However, we would also need to extend any non-PCI
> > device type we want to support with a driver_override attribute like
> > you did for PCI in 782a985d7af26db39e86070d28f987cad2 -- so this is
> > only for newer kernels. Adding that attribute for subchannels looks
> > feasible at a glance, but I have not tried to actually do it :)
> > 
> > Halil, do you think that would make sense?  
> 
> Looks doable. Did not quite figure out the details yet, but it seems
> that for PCI driver_override has more benefits than for cio (compared
> to simple unbind/bind), as matching and probing seems to be more
> elaborate for PCI. The benefit I see are
> 1) the ability to exclude the device form driver binding, and
> 2) having the same mechanism and thus consistent experience for pci and
> cio.

Yes, we should provide the same mechanism, even if it is much simpler
for the css bus.

> 
> What we IMHO should not do is make driver_override the override the
> sch->st == id->type check.

Agreed. The number of possible ids is much lower on the css bus, and a
driver wanting to match to any device may simply specify all of them
(not that this looks very useful).

I'm currently playing with this change; will send out a patch when I
have it in reasonable shape.

> 
> Regards,
> Halil
> 
> > 
> > [This might also help with the lcs vs. ctc confusion on a certain 3088
> > cu model if this is added for ccw devices as well; but I'm not sure if
> > these are still out in the wild at all. Probably not worth the effort
> > for that.]  
>