| Message ID | 1587725152-25569-8-git-send-email-pmorel@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | s390x: Testing the Channel Subsystem I/O | expand |
On 4/24/20 12:45 PM, Pierre Morel wrote: > A second step when testing the channel subsystem is to prepare a channel > for use. > This includes: > - Get the current SubCHannel Information Block (SCHIB) using STSCH > - Update it in memory to set the ENABLE bit > - Tell the CSS that the SCHIB has been modified using MSCH > - Get the SCHIB from the CSS again to verify that the subchannel is > enabled. > > This tests the MSCH instruction to enable a channel succesfuly. successfully > This is NOT a routine to really enable the channel, no retry is done, > in case of error, a report is made. Would we expect needing retries for the pong device? > > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> > --- > s390x/css.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 48 insertions(+) > > diff --git a/s390x/css.c b/s390x/css.c > index cc97e79..fa068bf 100644 > --- a/s390x/css.c > +++ b/s390x/css.c > @@ -68,11 +68,59 @@ out: > scn, scn_found, dev_found); > } > > +static void test_enable(void) > +{ > + struct pmcw *pmcw = &schib.pmcw; > + int cc; > + > + if (!test_device_sid) { > + report_skip("No device"); > + return; > + } If these tests are layered on top of each other and need a device to work, we should abort or skip and exit the test if the enumeration doesn't bring up devices > + /* Read the SCHIB for this subchannel */ > + cc = stsch(test_device_sid, &schib); > + if (cc) { > + report(0, "stsch cc=%d", cc); > + return; > + } > + > + /* Update the SCHIB to enable the channel */ > + pmcw->flags |= PMCW_ENABLE; > + > + /* Tell the CSS we want to modify the subchannel */ > + cc = msch(test_device_sid, &schib); > + if (cc) { > + /* > + * If the subchannel is status pending or > + * if a function is in progress, > + * we consider both cases as errors. > + */ > + report(0, "msch cc=%d", cc); > + return; > + } > + > + /* > + * Read the SCHIB again to verify the enablement > + */ > + cc = stsch(test_device_sid, &schib); > + if (cc) { > + report(0, "stsch cc=%d", cc); > + return; > + } > + > + if (!(pmcw->flags & PMCW_ENABLE)) { > + report(0, "Enable failed. pmcw: %x", pmcw->flags); > + return; > + } > + report(1, "Tested"); s/Tested/Enabled/ > +} > + > static struct { > const char *name; > void (*func)(void); > } tests[] = { > { "enumerate (stsch)", test_enumerate }, > + { "enable (msch)", test_enable }, > { NULL, NULL } > }; > >
On 2020-04-27 15:11, Janosch Frank wrote: > On 4/24/20 12:45 PM, Pierre Morel wrote: >> A second step when testing the channel subsystem is to prepare a channel >> for use. >> This includes: >> - Get the current SubCHannel Information Block (SCHIB) using STSCH >> - Update it in memory to set the ENABLE bit >> - Tell the CSS that the SCHIB has been modified using MSCH >> - Get the SCHIB from the CSS again to verify that the subchannel is >> enabled. >> >> This tests the MSCH instruction to enable a channel succesfuly. > > successfully Thx > >> This is NOT a routine to really enable the channel, no retry is done, >> in case of error, a report is made. > > Would we expect needing retries for the pong device? Yes it can be that we need to retry some instructions if we want them to succeed. This is the case for example if we develop a driver for an operating system. When working with firmware, sometime, things do not work at the first time. Mostly due to races in silicium, firmware or hypervisor or between them all. Since our purpose is to detect such problems we do not retry instructions but report the error. If we detect such problem we may in the future enhance the tests. > >> >> + >> + if (!test_device_sid) { >> + report_skip("No device"); >> + return; >> + } > > If these tests are layered on top of each other and need a device to > work, we should abort or skip and exit the test if the enumeration > doesn't bring up devices OK, we can abort instead of skipping >> + report(1, "Tested"); > > s/Tested/Enabled/ OK Thanks, Regards, Pierre
On Tue, 28 Apr 2020 10:27:36 +0200 Pierre Morel <pmorel@linux.ibm.com> wrote: > On 2020-04-27 15:11, Janosch Frank wrote: > > On 4/24/20 12:45 PM, Pierre Morel wrote: > >> This is NOT a routine to really enable the channel, no retry is done, > >> in case of error, a report is made. > > > > Would we expect needing retries for the pong device? > > Yes it can be that we need to retry some instructions if we want them to > succeed. > This is the case for example if we develop a driver for an operating system. > When working with firmware, sometime, things do not work at the first > time. Mostly due to races in silicium, firmware or hypervisor or between > them all. > > Since our purpose is to detect such problems we do not retry > instructions but report the error. > > If we detect such problem we may in the future enhance the tests. I think I've seen retries needed on z/VM in the past; do you know if that still happens?
On 2020-05-14 14:08, Cornelia Huck wrote: > On Tue, 28 Apr 2020 10:27:36 +0200 > Pierre Morel <pmorel@linux.ibm.com> wrote: > >> On 2020-04-27 15:11, Janosch Frank wrote: >>> On 4/24/20 12:45 PM, Pierre Morel wrote: > >>>> This is NOT a routine to really enable the channel, no retry is done, >>>> in case of error, a report is made. >>> >>> Would we expect needing retries for the pong device? >> >> Yes it can be that we need to retry some instructions if we want them to >> succeed. >> This is the case for example if we develop a driver for an operating system. >> When working with firmware, sometime, things do not work at the first >> time. Mostly due to races in silicium, firmware or hypervisor or between >> them all. >> >> Since our purpose is to detect such problems we do not retry >> instructions but report the error. >> >> If we detect such problem we may in the future enhance the tests. > > I think I've seen retries needed on z/VM in the past; do you know if > that still happens? > I did not try the tests under z/VM, nor direct on an LPAR, only under QEMU/KVM. Under QEMU/KVM, I did not encounter any need for retry, 100% of the enabled succeeded on first try. Regards, Pierre
On Fri, 15 May 2020 09:11:52 +0200 Pierre Morel <pmorel@linux.ibm.com> wrote: > On 2020-05-14 14:08, Cornelia Huck wrote: > > On Tue, 28 Apr 2020 10:27:36 +0200 > > Pierre Morel <pmorel@linux.ibm.com> wrote: > > > >> On 2020-04-27 15:11, Janosch Frank wrote: > >>> On 4/24/20 12:45 PM, Pierre Morel wrote: > > > >>>> This is NOT a routine to really enable the channel, no retry is done, > >>>> in case of error, a report is made. > >>> > >>> Would we expect needing retries for the pong device? > >> > >> Yes it can be that we need to retry some instructions if we want them to > >> succeed. > >> This is the case for example if we develop a driver for an operating system. > >> When working with firmware, sometime, things do not work at the first > >> time. Mostly due to races in silicium, firmware or hypervisor or between > >> them all. > >> > >> Since our purpose is to detect such problems we do not retry > >> instructions but report the error. > >> > >> If we detect such problem we may in the future enhance the tests. > > > > I think I've seen retries needed on z/VM in the past; do you know if > > that still happens? > > > > I did not try the tests under z/VM, nor direct on an LPAR, only under > QEMU/KVM. > Under QEMU/KVM, I did not encounter any need for retry, 100% of the > enabled succeeded on first try. Yep, QEMU/KVM should be fine. Do you plan to run this on anything else?
On 5/15/20 10:25 AM, Cornelia Huck wrote: > On Fri, 15 May 2020 09:11:52 +0200 > Pierre Morel <pmorel@linux.ibm.com> wrote: > >> On 2020-05-14 14:08, Cornelia Huck wrote: >>> On Tue, 28 Apr 2020 10:27:36 +0200 >>> Pierre Morel <pmorel@linux.ibm.com> wrote: >>> >>>> On 2020-04-27 15:11, Janosch Frank wrote: >>>>> On 4/24/20 12:45 PM, Pierre Morel wrote: >>> >>>>>> This is NOT a routine to really enable the channel, no retry is done, >>>>>> in case of error, a report is made. >>>>> >>>>> Would we expect needing retries for the pong device? >>>> >>>> Yes it can be that we need to retry some instructions if we want them to >>>> succeed. >>>> This is the case for example if we develop a driver for an operating system. >>>> When working with firmware, sometime, things do not work at the first >>>> time. Mostly due to races in silicium, firmware or hypervisor or between >>>> them all. >>>> >>>> Since our purpose is to detect such problems we do not retry >>>> instructions but report the error. >>>> >>>> If we detect such problem we may in the future enhance the tests. >>> >>> I think I've seen retries needed on z/VM in the past; do you know if >>> that still happens? >>> >> >> I did not try the tests under z/VM, nor direct on an LPAR, only under >> QEMU/KVM. >> Under QEMU/KVM, I did not encounter any need for retry, 100% of the >> enabled succeeded on first try. > > Yep, QEMU/KVM should be fine. Do you plan to run this on anything else? > I'd like to have it compatible with z/VM / LPAR as well if it isn't too much work. You never know when you need it and having tests for all hypervisors has been quite a help in the past.
On 2020-05-15 10:53, Janosch Frank wrote: > On 5/15/20 10:25 AM, Cornelia Huck wrote: >> On Fri, 15 May 2020 09:11:52 +0200 >> Pierre Morel <pmorel@linux.ibm.com> wrote: >> >>> On 2020-05-14 14:08, Cornelia Huck wrote: >>>> On Tue, 28 Apr 2020 10:27:36 +0200 >>>> Pierre Morel <pmorel@linux.ibm.com> wrote: >>>> >>>>> On 2020-04-27 15:11, Janosch Frank wrote: >>>>>> On 4/24/20 12:45 PM, Pierre Morel wrote: >>>> >>>>>>> This is NOT a routine to really enable the channel, no retry is done, >>>>>>> in case of error, a report is made. >>>>>> >>>>>> Would we expect needing retries for the pong device? >>>>> >>>>> Yes it can be that we need to retry some instructions if we want them to >>>>> succeed. >>>>> This is the case for example if we develop a driver for an operating system. >>>>> When working with firmware, sometime, things do not work at the first >>>>> time. Mostly due to races in silicium, firmware or hypervisor or between >>>>> them all. >>>>> >>>>> Since our purpose is to detect such problems we do not retry >>>>> instructions but report the error. >>>>> >>>>> If we detect such problem we may in the future enhance the tests. >>>> >>>> I think I've seen retries needed on z/VM in the past; do you know if >>>> that still happens? >>>> >>> >>> I did not try the tests under z/VM, nor direct on an LPAR, only under >>> QEMU/KVM. >>> Under QEMU/KVM, I did not encounter any need for retry, 100% of the >>> enabled succeeded on first try. >> >> Yep, QEMU/KVM should be fine. Do you plan to run this on anything else? >> > > I'd like to have it compatible with z/VM / LPAR as well if it isn't too > much work. You never know when you need it and having tests for all > hypervisors has been quite a help in the past. > OK, then I can add some retries in prevision.
diff --git a/s390x/css.c b/s390x/css.c index cc97e79..fa068bf 100644 --- a/s390x/css.c +++ b/s390x/css.c @@ -68,11 +68,59 @@ out: scn, scn_found, dev_found); } +static void test_enable(void) +{ + struct pmcw *pmcw = &schib.pmcw; + int cc; + + if (!test_device_sid) { + report_skip("No device"); + return; + } + /* Read the SCHIB for this subchannel */ + cc = stsch(test_device_sid, &schib); + if (cc) { + report(0, "stsch cc=%d", cc); + return; + } + + /* Update the SCHIB to enable the channel */ + pmcw->flags |= PMCW_ENABLE; + + /* Tell the CSS we want to modify the subchannel */ + cc = msch(test_device_sid, &schib); + if (cc) { + /* + * If the subchannel is status pending or + * if a function is in progress, + * we consider both cases as errors. + */ + report(0, "msch cc=%d", cc); + return; + } + + /* + * Read the SCHIB again to verify the enablement + */ + cc = stsch(test_device_sid, &schib); + if (cc) { + report(0, "stsch cc=%d", cc); + return; + } + + if (!(pmcw->flags & PMCW_ENABLE)) { + report(0, "Enable failed. pmcw: %x", pmcw->flags); + return; + } + report(1, "Tested"); +} + static struct { const char *name; void (*func)(void); } tests[] = { { "enumerate (stsch)", test_enumerate }, + { "enable (msch)", test_enable }, { NULL, NULL } };
A second step when testing the channel subsystem is to prepare a channel for use. This includes: - Get the current SubCHannel Information Block (SCHIB) using STSCH - Update it in memory to set the ENABLE bit - Tell the CSS that the SCHIB has been modified using MSCH - Get the SCHIB from the CSS again to verify that the subchannel is enabled. This tests the MSCH instruction to enable a channel succesfuly. This is NOT a routine to really enable the channel, no retry is done, in case of error, a report is made. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> --- s390x/css.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+)