Re: [libvirt] mdevctl: A shoestring mediated device management and persistence utility
On Wed, 12 Jun 2019 17:54:34 +0200
Halil Pasic <pasic(a)linux.ibm.com> wrote:
On Wed, 12 Jun 2019 09:14:39 +0200
Cornelia Huck <cohuck(a)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.]