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?
