Hi Conny,
Thank you for the ping. This is pending for a long time and we just resumed
looking at this approach. Me and Peter had a short discussion on this and we
are trying to do some cleaning as well on the CIO layer while working
with the
new approach.
There are few uncertainties with the new approach, which we would like
to clarify
and i am trying to test it.For example, the impact on the way
cio-console driver works.
So, as discussed with Peter, let me make a smaller draft which will
consolidate
your approach and the "cleaning" part that we would like to do.
As mentioned, i will resume working on this and get back to you with
myfindings.
Thank you,
Vineeth
On 9/14/20 1:46 PM, Cornelia Huck wrote:
<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...
