Re: [RFC v2 0/1]s390/cio: remove uevent suppress from cio driver

[Cornelia Huck <cohuck@redhat.com>]

On Wed, Nov 03 2021, Vineeth Vijayan <vneethv@linux.ibm.com> wrote:

>> > I think the potentially problematic case is "lots of I/O subchannels
>> with no valid device", and I think you can't get that under z/VM (which
>> will not give you those subchannels in the first place), but only on LPAR.
> Yes. But, this is in case of actual device. I just defined around 5k virtual
> dasd devices on zVM and did not enable them. i.e those subchannels are not
> blacklisted anymore, but they does not have an operational device. 
>
> other than zVM, other than testing this patch on different available LPARs,
> we tried to mimic the device availability with a custom test-kernel.
> Basically, modified the subchannel initialization code and inform the subchannel
> about the presence of a device, which then later fails during SNSID.
> It is a horrid way to test it, but i think it could simulate some LPARs with
> more than 1000 non-operational devices connected on it.

OK, that should be a way to figure out how userspace deals with the
extra uevents.

>
> ...snip...
>
>> - non-I/O subchannels (IIRC you can't have CHSC subchannels under z/VM,
>>   don't know about EADM, so that would need to be done on an LPAR as
>>   well)
> Thanks. Most of my tests were on IO-subchannel. I shall try few tests on CHSC
> and EADM.
>
>> - interaction with driverctl (and maybe mdevctl) for vfio-ccw
> I have done couple of tests with driverctl. Also, i was wondering if vfio-ccw
> can make use of 'dev_busid' sysfs-interface under each subchannels while writing
> the rules. This is totally different topic, which i do not want to mix up in
> this thread.

Oh, did not know about that interface.

<looks>
Doesn't the code need to check for 'w' for message subchannels, though?

'dev_busid' looks like a good fit for udev rules; maybe driverctl needs
special-casing? Or does it belong into mdevctl? cc:ing vfio-ccw
maintainers for awareness :)