On 2019-12-02 15:30, Cornelia Huck wrote:
On Thu, 28 Nov 2019 13:46:05 +0100
Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote:
A second step when testing the channel subsystem is to prepare a channel
for use.
This tests the success of the MSCH instruction by enabling a channel.
Signed-off-by: Pierre Morel <pmorel@xxxxxxxxxxxxx>
---
s390x/css.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/s390x/css.c b/s390x/css.c
index 8186f55..e42dc2f 100644
--- a/s390x/css.c
+++ b/s390x/css.c
@@ -62,11 +62,38 @@ static void test_enumerate(void)
return;
}
+static void set_schib(void)
+{
+ struct pmcw *p = &schib.pmcw;
+
+ p->intparm = 0xdeadbeef;
+ p->flags |= PMCW_ENABLE;
+}
+
+static void test_enable(void)
+{
+ int ret;
+
+ if (!test_device_sid) {
+ report_skip("No device");
+ return;
+ }
+ set_schib();
+ dump_schib(&schib);
+
+ ret = msch(test_device_sid, &schib);
+ if (ret)
+ report("msch cc=%d", 0, ret);
Maybe do a stsch and then check/dump the contents of the schib again?
Background: The architecture allows that msch returns success, but that
the fields modified by the issuer remain unchanged at the subchannel
regardless. That should not happen with QEMU; but I remember versions
of z/VM where we sometimes had to call msch twice to make changes stick.
OK, thanks, good advice
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
