On Sat, 19 Dec 2020 08:20:06 +0100
Halil Pasic <pasic@xxxxxxxxxxxxx> wrote:
> On Wed, 16 Dec 2020 13:07:10 +0100
> Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
>
> > On Wed, 16 Dec 2020 12:53:41 +0100
> > Boris Fiuczynski <fiuczy@xxxxxxxxxxxxx> 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.
But ccw does not provide driver_override? Confused.
>
> 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?
I have not really looked at how to implement this. But we could have
driverctl support an optional "additional_parameters" option, which
allows to specify key/value pairs that have to match. I guess that
should be dropped into the driverctl config directory, and generate an
additional check?
