Re: [RFC 1/1] s390/cio: Remove uevent-suppress from css driver

[Halil Pasic <pasic@linux.ibm.com>]

On Wed, 16 Dec 2020 13:07:10 +0100
Cornelia Huck <cohuck@redhat.com> wrote:

> On Wed, 16 Dec 2020 12:53:41 +0100
> Boris Fiuczynski <fiuczy@linux.ibm.com> wrote:
> 
> > On 12/15/20 7:13 PM, Cornelia Huck wrote:
> > >>     
> > >>> I'm not sure how many rules actually care about events for the
> > >>> subchannel device; the ccw device seems like the more helpful device to
> > >>> watch out for.  
> > >> I tend to agree, but the problem with vfio-ccw is that (currently) we
> > >> don't have a ccw device in the host, because we pass-through the
> > >> subchannel. When we interrogate the subchannel, we do learn if there
> > >> is a device and if, what is its devno. If I were to run a system with
> > >> vfio-ccw passthrough, I would want to passthrough the subchannel that
> > >> talks to the DASD (identified by devno) I need passed through to my
> > >> guest.  
> > > I think that can be solved by simply adding the devno as a variable to
> > > the uevent (valid if it's an I/O subchannel; we don't register the
> > > subchannel in the first place if dnv is not set.)
> > >   
> > Providing the devno in the context of the udev event certainly helps if 
> > the event consumer would base its actions on it.
> > As far as I understand the driver_override mechanics driverctl sets the 
> > override based on a specified device. In that case the devno would not 
> > be looked at and the subchannel would end up with a vfio-ccw driver even 
> > so the ccw device might not be the one we want to use as pass-through 
> > device.
> 
> Hm, maybe we need to make a change in driverctl that allows per-bus
> custom rules?
> 

The issue with that is, that this problem ain't bus specific. I.e. it
could make perfect sense to driver_override a certain ccw tape device to
an alternative tape driver.

The problem is, that the only way driverctl can identify a device is a
(name_of_the_bus), device_name_on_the bus) pair. Currently the udev rule
installed by driverctl simply ooks fora file 
/etc/driverctl.d/$env{SUBSYSTEM}-$kernel
which basically encodes the current selection criteria.

Can yo please elaborate on your idea? How would you extend the driverctl
cli and how would persistence look like for these custom rules? Would
you make driverctl write an udev rule for each such device/custom rule
on 'set-override' command instead of file in /etc/driverctl.d?

Regards,
Halil