On Wed, Nov 03 2021, Vineeth Vijayan <vneethv@xxxxxxxxxxxxx> 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 :)
