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.
> + else
> + report("Tested", 1);
> +}
> +
> static struct {
> const char *name;
> void (*func)(void);
> } tests[] = {
> { "enumerate (stsch)", test_enumerate },
> + { "enable (msch)", test_enable },
> { NULL, NULL }
> };
>
