From: Vineeth Vijayan <vneethv@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>, linux-s390@vger.kernel.org
Cc: oberpar@linux.ibm.com
Subject: Re: [RFC v2 0/1]s390/cio: remove uevent suppress from cio driver
Date: Wed, 03 Nov 2021 14:17:57 +0100 [thread overview]
Message-ID: <3ab690456a523951ad59c17ac71e6b294ff12d98.camel@linux.ibm.com> (raw)
In-Reply-To: <87lf26bmlq.fsf@redhat.com>
Thank you Conny for looking in to this.
On Tue, 2021-11-02 at 16:31 +0100, Cornelia Huck wrote:
...snip...
> device has bound to a driver, which was an information that was
> completely missing up to now for subchannels. The main issue is that the
> subchannel will get deregistered again (or has that been changed? Sorry,
> I've been out of the loop for too long...)
You are right. There is a change and we do not unregister the subchannel if we
find the corresponding device is not operational or empty.
...snip...
> > 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.
...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.
...snip...
next prev parent reply other threads:[~2021-11-03 13:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 8:50 [RFC v2 0/1]s390/cio: remove uevent suppress from cio driver Vineeth Vijayan
2021-10-27 8:50 ` [PATCH] s390/cio: " Vineeth Vijayan
2021-11-02 15:42 ` Cornelia Huck
2021-11-02 15:31 ` [RFC v2 0/1]s390/cio: " Cornelia Huck
2021-11-03 13:17 ` Vineeth Vijayan [this message]
2021-11-03 15:41 ` Cornelia Huck
2021-11-05 14:11 ` Vineeth Vijayan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ab690456a523951ad59c17ac71e6b294ff12d98.camel@linux.ibm.com \
--to=vneethv@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=linux-s390@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox