<casts "reanimate" on dead thread> On Wed, 1 Jul 2020 11:23:13 +0200 Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > On Mon, 29 Jun 2020 13:56:31 +0200 > Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > > > Ok, so I've resumed the thinking process, and I think getting rid of > > the "no I/O subchannel without functional device" approach is a good > > idea, and allows us to make handling driver matches more similar to > > everyone else. > > As an aside, there's another odd construct: the I/O subchannel driver > *always* binds to the subchannel device, even if there is a problem, > and schedules an unregistration of the subchannel device on error. This > was introduced because events from machine check handling are not > processed if there isn't a driver (at least I thought back then that it > was a good idea.) I think a more correct way to handle this would be to > do the following: > > * If something doesn't work, clean up and return an error in the probe > function. The subchannel device stays around, it's just not bound. > * Have the css bus do some basic processing for subchannels not bound > to any driver (e.g., check dnv/w). This would also make it possible > to unregister dead message subchannels if a machine check is received > for them (don't know if that's an actual problem in pratice.) > > > > > What changes would be needed? > > * The whole logic to suppress uevents for subchannels and generate one > > later will go. (Touches the various subchannel driver, including > > vfio-ccw.) > > * ccw_device_todo() can just unregister the ccw device, and there's no > > longer a need for ccw_device_call_sch_unregister(). (IIUC, this also > > covers setting disconnected devices offline.) > > I'm actually not sure if unregistration-by-driver is the right thing > for most cases (except for something like disconnected device removal), > that should be done by the bus. Maybe something for later (don't fear, > I don't plan to work on the common I/O layer again :) > > > * As the I/O subchannel driver now needs to deal with cases where no > > ccw device is available, the code for that needs to be checked. > > (That's probably the most time-consuming task.) > > Had a quick look, doesn't actually look too bad (most places already > check for !cdev.) > > > > > Userspace should be fine with I/O subchannels without ccw device, > > that's nothing new. > > > > Does that sound reasonable? Is anybody looking at this? The delayed uevent handling is a bit of a mess for management of vfio-ccw devices...
