| Message ID | 1589818051-20549-9-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 18/05/2020 18.07, Pierre Morel wrote: > First step for testing the channel subsystem is to enumerate the css and > retrieve the css devices. > > This tests the success of STSCH I/O instruction, we do not test the > reaction of the VM for an instruction with wrong parameters. > > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> > --- > s390x/Makefile | 1 + > s390x/css.c | 89 +++++++++++++++++++++++++++++++++++++++++++++ > s390x/unittests.cfg | 4 ++ > 3 files changed, 94 insertions(+) > create mode 100644 s390x/css.c [...] > diff --git a/s390x/unittests.cfg b/s390x/unittests.cfg > index 07013b2..a436ec0 100644 > --- a/s390x/unittests.cfg > +++ b/s390x/unittests.cfg > @@ -83,3 +83,7 @@ extra_params = -m 1G > [sclp-3g] > file = sclp.elf > extra_params = -m 3G > + > +[css] > +file = css.elf > +extra_params =-device ccw-pong I gave your patch series a try on a normal upstream QEMU (that does not have the ccw-pong device yet), and the css test of course fails there, since QEMU bails out with: -device ccw-pong: 'ccw-pong' is not a valid device model name This is unfortunate - I think we likely have to deal with QEMUs for quite a while that do not have this device enabled. Could you maybe add some kind of check to the kvm-unit-tests scripts that only run a test if a given device is available, and skip the test otherwise? Thomas
On 5/25/20 9:12 PM, Thomas Huth wrote: > On 18/05/2020 18.07, Pierre Morel wrote: >> First step for testing the channel subsystem is to enumerate the css and >> retrieve the css devices. >> >> This tests the success of STSCH I/O instruction, we do not test the >> reaction of the VM for an instruction with wrong parameters. >> >> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> >> --- >> s390x/Makefile | 1 + >> s390x/css.c | 89 +++++++++++++++++++++++++++++++++++++++++++++ >> s390x/unittests.cfg | 4 ++ >> 3 files changed, 94 insertions(+) >> create mode 100644 s390x/css.c > [...] >> diff --git a/s390x/unittests.cfg b/s390x/unittests.cfg >> index 07013b2..a436ec0 100644 >> --- a/s390x/unittests.cfg >> +++ b/s390x/unittests.cfg >> @@ -83,3 +83,7 @@ extra_params = -m 1G >> [sclp-3g] >> file = sclp.elf >> extra_params = -m 3G >> + >> +[css] >> +file = css.elf >> +extra_params =-device ccw-pong > > I gave your patch series a try on a normal upstream QEMU (that does not > have the ccw-pong device yet), and the css test of course fails there, > since QEMU bails out with: > > -device ccw-pong: 'ccw-pong' is not a valid device model name > > This is unfortunate - I think we likely have to deal with QEMUs for > quite a while that do not have this device enabled. Could you maybe add > some kind of check to the kvm-unit-tests scripts that only run a test if > a given device is available, and skip the test otherwise? > > Thomas > Could we for now remove it from unittests.cfg and let Pierre come up with a solution without delaying this whole series? I expect changes to run_tests.sh to attract a rather long discussion...
On 26/05/2020 12.41, Janosch Frank wrote: > On 5/25/20 9:12 PM, Thomas Huth wrote: >> On 18/05/2020 18.07, Pierre Morel wrote: >>> First step for testing the channel subsystem is to enumerate the css and >>> retrieve the css devices. >>> >>> This tests the success of STSCH I/O instruction, we do not test the >>> reaction of the VM for an instruction with wrong parameters. >>> >>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> >>> --- >>> s390x/Makefile | 1 + >>> s390x/css.c | 89 +++++++++++++++++++++++++++++++++++++++++++++ >>> s390x/unittests.cfg | 4 ++ >>> 3 files changed, 94 insertions(+) >>> create mode 100644 s390x/css.c >> [...] >>> diff --git a/s390x/unittests.cfg b/s390x/unittests.cfg >>> index 07013b2..a436ec0 100644 >>> --- a/s390x/unittests.cfg >>> +++ b/s390x/unittests.cfg >>> @@ -83,3 +83,7 @@ extra_params = -m 1G >>> [sclp-3g] >>> file = sclp.elf >>> extra_params = -m 3G >>> + >>> +[css] >>> +file = css.elf >>> +extra_params =-device ccw-pong >> >> I gave your patch series a try on a normal upstream QEMU (that does not >> have the ccw-pong device yet), and the css test of course fails there, >> since QEMU bails out with: >> >> -device ccw-pong: 'ccw-pong' is not a valid device model name >> >> This is unfortunate - I think we likely have to deal with QEMUs for >> quite a while that do not have this device enabled. Could you maybe add >> some kind of check to the kvm-unit-tests scripts that only run a test if >> a given device is available, and skip the test otherwise? >> >> Thomas >> > > Could we for now remove it from unittests.cfg and let Pierre come up > with a solution without delaying this whole series? I expect changes to > run_tests.sh to attract a rather long discussion... Fine for me, too. Thomas
On 2020-05-26 12:49, Thomas Huth wrote: > On 26/05/2020 12.41, Janosch Frank wrote: >> On 5/25/20 9:12 PM, Thomas Huth wrote: >>> On 18/05/2020 18.07, Pierre Morel wrote: >>>> First step for testing the channel subsystem is to enumerate the css and >>>> retrieve the css devices. ...snip... >>> I gave your patch series a try on a normal upstream QEMU (that does not >>> have the ccw-pong device yet), and the css test of course fails there, >>> since QEMU bails out with: >>> >>> -device ccw-pong: 'ccw-pong' is not a valid device model name >>> >>> This is unfortunate - I think we likely have to deal with QEMUs for >>> quite a while that do not have this device enabled. Could you maybe add >>> some kind of check to the kvm-unit-tests scripts that only run a test if >>> a given device is available, and skip the test otherwise? >>> >>> Thomas >>> >> >> Could we for now remove it from unittests.cfg and let Pierre come up >> with a solution without delaying this whole series? I expect changes to >> run_tests.sh to attract a rather long discussion... > > Fine for me, too. > > Thomas > OK, thanks you both, I do so, take the unittest.cfg out from this series and come back later with a proposition for unittest.cfg. Regards, Pierre
On Mon, 18 May 2020 18:07:27 +0200 Pierre Morel <pmorel@linux.ibm.com> wrote: > First step for testing the channel subsystem is to enumerate the css and > retrieve the css devices. > > This tests the success of STSCH I/O instruction, we do not test the > reaction of the VM for an instruction with wrong parameters. > > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> > --- > s390x/Makefile | 1 + > s390x/css.c | 89 +++++++++++++++++++++++++++++++++++++++++++++ > s390x/unittests.cfg | 4 ++ > 3 files changed, 94 insertions(+) > create mode 100644 s390x/css.c (...) > +static void test_enumerate(void) > +{ > + struct pmcw *pmcw = &schib.pmcw; > + int cc; > + int scn; > + int scn_found = 0; > + int dev_found = 0; > + > + for (scn = 0; scn < 0xffff; scn++) { > + cc = stsch(scn|SID_ONE, &schib); > + switch (cc) { > + case 0: /* 0 means SCHIB stored */ > + break; > + case 3: /* 3 means no more channels */ > + goto out; > + default: /* 1 or 2 should never happened for STSCH */ > + report(0, "Unexpected cc=%d on subchannel number 0x%x", > + cc, scn); > + return; > + } > + > + /* We currently only support type 0, a.k.a. I/O channels */ > + if (PMCW_CHANNEL_TYPE(pmcw) != 0) > + continue; > + > + /* We ignore I/O channels without valid devices */ > + scn_found++; > + if (!(pmcw->flags & PMCW_DNV)) > + continue; > + > + /* We keep track of the first device as our test device */ > + if (!test_device_sid) > + test_device_sid = scn | SID_ONE; > + > + dev_found++; > + } > + > +out: > + report(dev_found, > + "Tested subchannels: %d, I/O subchannels: %d, I/O devices: %d", > + scn, scn_found, dev_found); Just wondering: with the current invocation, you expect to find exactly one subchannel with a valid device, right? > +} > + > +static struct { > + const char *name; > + void (*func)(void); > +} tests[] = { > + { "enumerate (stsch)", test_enumerate }, > + { NULL, NULL } > +}; > + > +int main(int argc, char *argv[]) > +{ > + int i; > + > + report_prefix_push("Channel Subsystem"); > + for (i = 0; tests[i].name; i++) { > + report_prefix_push(tests[i].name); > + tests[i].func(); > + report_prefix_pop(); > + } > + report_prefix_pop(); > + > + return report_summary(); > +} > diff --git a/s390x/unittests.cfg b/s390x/unittests.cfg > index 07013b2..a436ec0 100644 > --- a/s390x/unittests.cfg > +++ b/s390x/unittests.cfg > @@ -83,3 +83,7 @@ extra_params = -m 1G > [sclp-3g] > file = sclp.elf > extra_params = -m 3G > + > +[css] > +file = css.elf > +extra_params =-device ccw-pong Hm... you could test enumeration even with a QEMU that does not include support for the pong device, right? Would it be worthwhile to split out a set of css tests that use e.g. a virtio-net-ccw device, and have a css-pong set of tests that require the pong device?
On 2020-05-27 10:55, Cornelia Huck wrote: > On Mon, 18 May 2020 18:07:27 +0200 > Pierre Morel <pmorel@linux.ibm.com> wrote: > >> First step for testing the channel subsystem is to enumerate the css and >> retrieve the css devices. >> >> This tests the success of STSCH I/O instruction, we do not test the >> reaction of the VM for an instruction with wrong parameters. >> >> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> >> --- >> s390x/Makefile | 1 + >> s390x/css.c | 89 +++++++++++++++++++++++++++++++++++++++++++++ >> s390x/unittests.cfg | 4 ++ >> 3 files changed, 94 insertions(+) >> create mode 100644 s390x/css.c > > (...) > >> +static void test_enumerate(void) >> +{ >> + struct pmcw *pmcw = &schib.pmcw; >> + int cc; >> + int scn; >> + int scn_found = 0; >> + int dev_found = 0; >> + >> + for (scn = 0; scn < 0xffff; scn++) { >> + cc = stsch(scn|SID_ONE, &schib); >> + switch (cc) { >> + case 0: /* 0 means SCHIB stored */ >> + break; >> + case 3: /* 3 means no more channels */ >> + goto out; >> + default: /* 1 or 2 should never happened for STSCH */ >> + report(0, "Unexpected cc=%d on subchannel number 0x%x", >> + cc, scn); >> + return; >> + } >> + >> + /* We currently only support type 0, a.k.a. I/O channels */ >> + if (PMCW_CHANNEL_TYPE(pmcw) != 0) >> + continue; >> + >> + /* We ignore I/O channels without valid devices */ >> + scn_found++; >> + if (!(pmcw->flags & PMCW_DNV)) >> + continue; >> + >> + /* We keep track of the first device as our test device */ >> + if (!test_device_sid) >> + test_device_sid = scn | SID_ONE; >> + >> + dev_found++; >> + } >> + >> +out: >> + report(dev_found, >> + "Tested subchannels: %d, I/O subchannels: %d, I/O devices: %d", >> + scn, scn_found, dev_found); > > Just wondering: with the current invocation, you expect to find exactly > one subchannel with a valid device, right? ...snip... >> diff --git a/s390x/unittests.cfg b/s390x/unittests.cfg >> index 07013b2..a436ec0 100644 >> --- a/s390x/unittests.cfg >> +++ b/s390x/unittests.cfg >> @@ -83,3 +83,7 @@ extra_params = -m 1G >> [sclp-3g] >> file = sclp.elf >> extra_params = -m 3G >> + >> +[css] >> +file = css.elf >> +extra_params =-device ccw-pong > > Hm... you could test enumeration even with a QEMU that does not include > support for the pong device, right? Would it be worthwhile to split out > a set of css tests that use e.g. a virtio-net-ccw device, and have a > css-pong set of tests that require the pong device? > Yes, you are right, using a virtio-net-ccw will allow to keep this test without waiting for the PONG device to exist. @Thomas, what do you think? I will still have to figure something out for PONG tests but here, it should be OK with virtio-net-ccw. Thanks a lot for the solution, :) Regards, Pierre
On 04/06/2020 13.35, Pierre Morel wrote: > > > On 2020-05-27 10:55, Cornelia Huck wrote: >> On Mon, 18 May 2020 18:07:27 +0200 >> Pierre Morel <pmorel@linux.ibm.com> wrote: >> >>> First step for testing the channel subsystem is to enumerate the css and >>> retrieve the css devices. >>> >>> This tests the success of STSCH I/O instruction, we do not test the >>> reaction of the VM for an instruction with wrong parameters. >>> >>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> >>> --- >>> s390x/Makefile | 1 + >>> s390x/css.c | 89 +++++++++++++++++++++++++++++++++++++++++++++ >>> s390x/unittests.cfg | 4 ++ >>> 3 files changed, 94 insertions(+) >>> create mode 100644 s390x/css.c >> >> (...) >> >>> +static void test_enumerate(void) >>> +{ >>> + struct pmcw *pmcw = &schib.pmcw; >>> + int cc; >>> + int scn; >>> + int scn_found = 0; >>> + int dev_found = 0; >>> + >>> + for (scn = 0; scn < 0xffff; scn++) { >>> + cc = stsch(scn|SID_ONE, &schib); >>> + switch (cc) { >>> + case 0: /* 0 means SCHIB stored */ >>> + break; >>> + case 3: /* 3 means no more channels */ >>> + goto out; >>> + default: /* 1 or 2 should never happened for STSCH */ >>> + report(0, "Unexpected cc=%d on subchannel number 0x%x", >>> + cc, scn); >>> + return; >>> + } >>> + >>> + /* We currently only support type 0, a.k.a. I/O channels */ >>> + if (PMCW_CHANNEL_TYPE(pmcw) != 0) >>> + continue; >>> + >>> + /* We ignore I/O channels without valid devices */ >>> + scn_found++; >>> + if (!(pmcw->flags & PMCW_DNV)) >>> + continue; >>> + >>> + /* We keep track of the first device as our test device */ >>> + if (!test_device_sid) >>> + test_device_sid = scn | SID_ONE; >>> + >>> + dev_found++; >>> + } >>> + >>> +out: >>> + report(dev_found, >>> + "Tested subchannels: %d, I/O subchannels: %d, I/O >>> devices: %d", >>> + scn, scn_found, dev_found); >> >> Just wondering: with the current invocation, you expect to find exactly >> one subchannel with a valid device, right? > ...snip... > >>> diff --git a/s390x/unittests.cfg b/s390x/unittests.cfg >>> index 07013b2..a436ec0 100644 >>> --- a/s390x/unittests.cfg >>> +++ b/s390x/unittests.cfg >>> @@ -83,3 +83,7 @@ extra_params = -m 1G >>> [sclp-3g] >>> file = sclp.elf >>> extra_params = -m 3G >>> + >>> +[css] >>> +file = css.elf >>> +extra_params =-device ccw-pong >> >> Hm... you could test enumeration even with a QEMU that does not include >> support for the pong device, right? Would it be worthwhile to split out >> a set of css tests that use e.g. a virtio-net-ccw device, and have a >> css-pong set of tests that require the pong device? >> > > Yes, you are right, using a virtio-net-ccw will allow to keep this test > without waiting for the PONG device to exist. > > @Thomas, what do you think? I will still have to figure something out > for PONG tests but here, it should be OK with virtio-net-ccw. Sure, sounds good. We can go with -device virtio-net-ccw for now, and then later add an additional entry a la: [css-pong] file = css.elf device = ccw-pong ... where the test scripts then check for the availability of the device first before starting the test? Thomas
On 2020-06-04 13:45, Thomas Huth wrote: > On 04/06/2020 13.35, Pierre Morel wrote: >> >> >> On 2020-05-27 10:55, Cornelia Huck wrote: >>> On Mon, 18 May 2020 18:07:27 +0200 >>> Pierre Morel <pmorel@linux.ibm.com> wrote: >>> >>>> First step for testing the channel subsystem is to enumerate the css and >>>> retrieve the css devices. >>>> >>>> This tests the success of STSCH I/O instruction, we do not test the >>>> reaction of the VM for an instruction with wrong parameters. >>>> >>>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> >>>> --- >>>> s390x/Makefile | 1 + >>>> s390x/css.c | 89 +++++++++++++++++++++++++++++++++++++++++++++ >>>> s390x/unittests.cfg | 4 ++ >>>> 3 files changed, 94 insertions(+) >>>> create mode 100644 s390x/css.c >>> >>> (...) >>> >>>> +static void test_enumerate(void) >>>> +{ >>>> + struct pmcw *pmcw = &schib.pmcw; >>>> + int cc; >>>> + int scn; >>>> + int scn_found = 0; >>>> + int dev_found = 0; >>>> + >>>> + for (scn = 0; scn < 0xffff; scn++) { >>>> + cc = stsch(scn|SID_ONE, &schib); >>>> + switch (cc) { >>>> + case 0: /* 0 means SCHIB stored */ >>>> + break; >>>> + case 3: /* 3 means no more channels */ >>>> + goto out; >>>> + default: /* 1 or 2 should never happened for STSCH */ >>>> + report(0, "Unexpected cc=%d on subchannel number 0x%x", >>>> + cc, scn); >>>> + return; >>>> + } >>>> + >>>> + /* We currently only support type 0, a.k.a. I/O channels */ >>>> + if (PMCW_CHANNEL_TYPE(pmcw) != 0) >>>> + continue; >>>> + >>>> + /* We ignore I/O channels without valid devices */ >>>> + scn_found++; >>>> + if (!(pmcw->flags & PMCW_DNV)) >>>> + continue; >>>> + >>>> + /* We keep track of the first device as our test device */ >>>> + if (!test_device_sid) >>>> + test_device_sid = scn | SID_ONE; >>>> + >>>> + dev_found++; >>>> + } >>>> + >>>> +out: >>>> + report(dev_found, >>>> + "Tested subchannels: %d, I/O subchannels: %d, I/O >>>> devices: %d", >>>> + scn, scn_found, dev_found); >>> >>> Just wondering: with the current invocation, you expect to find exactly >>> one subchannel with a valid device, right? >> ...snip... >> >>>> diff --git a/s390x/unittests.cfg b/s390x/unittests.cfg >>>> index 07013b2..a436ec0 100644 >>>> --- a/s390x/unittests.cfg >>>> +++ b/s390x/unittests.cfg >>>> @@ -83,3 +83,7 @@ extra_params = -m 1G >>>> [sclp-3g] >>>> file = sclp.elf >>>> extra_params = -m 3G >>>> + >>>> +[css] >>>> +file = css.elf >>>> +extra_params =-device ccw-pong >>> >>> Hm... you could test enumeration even with a QEMU that does not include >>> support for the pong device, right? Would it be worthwhile to split out >>> a set of css tests that use e.g. a virtio-net-ccw device, and have a >>> css-pong set of tests that require the pong device? >>> >> >> Yes, you are right, using a virtio-net-ccw will allow to keep this test >> without waiting for the PONG device to exist. >> >> @Thomas, what do you think? I will still have to figure something out >> for PONG tests but here, it should be OK with virtio-net-ccw. > > Sure, sounds good. We can go with -device virtio-net-ccw for now, and > then later add an additional entry a la: > > [css-pong] > file = css.elf > device = ccw-pong > > ... where the test scripts then check for the availability of the device > first before starting the test? > > Thomas > yes, thanks, Pierre
diff --git a/s390x/Makefile b/s390x/Makefile index 050c40b..baebf18 100644 --- a/s390x/Makefile +++ b/s390x/Makefile @@ -17,6 +17,7 @@ tests += $(TEST_DIR)/stsi.elf tests += $(TEST_DIR)/skrf.elf tests += $(TEST_DIR)/smp.elf tests += $(TEST_DIR)/sclp.elf +tests += $(TEST_DIR)/css.elf tests_binary = $(patsubst %.elf,%.bin,$(tests)) all: directories test_cases test_cases_binary diff --git a/s390x/css.c b/s390x/css.c new file mode 100644 index 0000000..d7989d8 --- /dev/null +++ b/s390x/css.c @@ -0,0 +1,89 @@ +/* + * Channel Subsystem tests + * + * Copyright (c) 2020 IBM Corp + * + * Authors: + * Pierre Morel <pmorel@linux.ibm.com> + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2. + */ + +#include <libcflat.h> +#include <alloc_phys.h> +#include <asm/page.h> +#include <string.h> +#include <interrupt.h> +#include <asm/arch_def.h> + +#include <css.h> + +static struct schib schib; +static int test_device_sid; + +static void test_enumerate(void) +{ + struct pmcw *pmcw = &schib.pmcw; + int cc; + int scn; + int scn_found = 0; + int dev_found = 0; + + for (scn = 0; scn < 0xffff; scn++) { + cc = stsch(scn|SID_ONE, &schib); + switch (cc) { + case 0: /* 0 means SCHIB stored */ + break; + case 3: /* 3 means no more channels */ + goto out; + default: /* 1 or 2 should never happened for STSCH */ + report(0, "Unexpected cc=%d on subchannel number 0x%x", + cc, scn); + return; + } + + /* We currently only support type 0, a.k.a. I/O channels */ + if (PMCW_CHANNEL_TYPE(pmcw) != 0) + continue; + + /* We ignore I/O channels without valid devices */ + scn_found++; + if (!(pmcw->flags & PMCW_DNV)) + continue; + + /* We keep track of the first device as our test device */ + if (!test_device_sid) + test_device_sid = scn | SID_ONE; + + dev_found++; + } + +out: + report(dev_found, + "Tested subchannels: %d, I/O subchannels: %d, I/O devices: %d", + scn, scn_found, dev_found); +} + +static struct { + const char *name; + void (*func)(void); +} tests[] = { + { "enumerate (stsch)", test_enumerate }, + { NULL, NULL } +}; + +int main(int argc, char *argv[]) +{ + int i; + + report_prefix_push("Channel Subsystem"); + for (i = 0; tests[i].name; i++) { + report_prefix_push(tests[i].name); + tests[i].func(); + report_prefix_pop(); + } + report_prefix_pop(); + + return report_summary(); +} diff --git a/s390x/unittests.cfg b/s390x/unittests.cfg index 07013b2..a436ec0 100644 --- a/s390x/unittests.cfg +++ b/s390x/unittests.cfg @@ -83,3 +83,7 @@ extra_params = -m 1G [sclp-3g] file = sclp.elf extra_params = -m 3G + +[css] +file = css.elf +extra_params =-device ccw-pong
First step for testing the channel subsystem is to enumerate the css and retrieve the css devices. This tests the success of STSCH I/O instruction, we do not test the reaction of the VM for an instruction with wrong parameters. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> --- s390x/Makefile | 1 + s390x/css.c | 89 +++++++++++++++++++++++++++++++++++++++++++++ s390x/unittests.cfg | 4 ++ 3 files changed, 94 insertions(+) create mode 100644 s390x/css.c