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

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

On Mon, 21 Dec 2020 16:52:19 +0100
Cornelia Huck <cohuck@redhat.com> wrote:

> On Sat, 19 Dec 2020 08:20:06 +0100
> Halil Pasic <pasic@linux.ibm.com> wrote:
> 
> > 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.
> 
> But ccw does not provide driver_override? Confused.
> 

Right, but it could. That is not my point. I was arguing with 'per-bus
custom rules'.

> > 
> > 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?
> 

The devil is always in the details. I'm sure something can be done :).
Key/value pairs for matching fits IMHO better with new udev rules than
with files in the driverctl config dir that somehow generate additiona
checks. One thing I didn't understand is, are you proposing an invocation
like 
driverctl -b css --additional_params="DEVNO=<devno>" \
set-override <subchannel_no> vfio_ccw
or 
driverctl -b css --additional_params="DEVNO=<devno>" \
set-override vfio_ccw
?

The first one would safeguard against passing through the wrong devno,
but I think, we actually want to be oblivious about the subchannel
number.

Regards,
Halil