public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	frankja@linux.ibm.com, david@redhat.com, thuth@redhat.com,
	drjones@redhat.com
Subject: Re: [kvm-unit-tests PATCH v10 9/9] s390x: css: ssch/tsch with sense and interrupt
Date: Mon, 6 Jul 2020 15:01:50 +0200	[thread overview]
Message-ID: <02eb7a70-7a74-6f09-334f-004e69aaa198@linux.ibm.com> (raw)
In-Reply-To: <20200706114655.5088b6b7.cohuck@redhat.com>



On 2020-07-06 11:46, Cornelia Huck wrote:
> On Thu,  2 Jul 2020 18:31:20 +0200
> Pierre Morel <pmorel@linux.ibm.com> wrote:
> 
>> After a channel is enabled we start a SENSE_ID command using
>> the SSCH instruction to recognize the control unit and device.
>>
>> This tests the success of SSCH, the I/O interruption and the TSCH
>> instructions.
>>
>> The SENSE_ID command response is tested to report 0xff inside
>> its reserved field and to report the same control unit type
>> as the cu_type kernel argument.
>>
>> Without the cu_type kernel argument, the test expects a device
>> with a default control unit type of 0x3832, a.k.a virtio-net-ccw.
>>
>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>> ---
>>   lib/s390x/asm/arch_def.h |   1 +
>>   lib/s390x/css.h          |  32 ++++++++-
>>   lib/s390x/css_lib.c      | 148 ++++++++++++++++++++++++++++++++++++++-
>>   s390x/css.c              |  94 ++++++++++++++++++++++++-
>>   4 files changed, 272 insertions(+), 3 deletions(-)
> 
> (...)
> 
>> -int css_enable(int schid)
>> +/*
>> + * css_enable: enable Subchannel
>> + * @schid: Subchannel Identifier
>> + * @isc: Interruption subclass for this subchannel as a number
> 
> "number of the interruption subclass to use"?

Yes, thanks.

> 
>> + * Return value:
>> + *   On success: 0
>> + *   On error the CC of the faulty instruction
>> + *      or -1 if the retry count is exceeded.
>> + *
>> + */
>> +int css_enable(int schid, int isc)
>>   {
>>   	struct pmcw *pmcw = &schib.pmcw;
>>   	int retry_count = 0;
>> @@ -92,6 +103,9 @@ retry:
>>   	/* Update the SCHIB to enable the channel */
>>   	pmcw->flags |= PMCW_ENABLE;
>>   
>> +	/* Set Interruption Subclass to IO_SCH_ISC */
> 
> The specified isc, current callers just happen to pass that value.
> 

Forgot to remove this comment. Will do.

>> +	pmcw->flags |= (isc << PMCW_ISC_SHIFT);
>> +
>>   	/* Tell the CSS we want to modify the subchannel */
>>   	cc = msch(schid, &schib);
>>   	if (cc) {
>> @@ -114,6 +128,7 @@ retry:
>>   		return cc;
>>   	}
>>   
>> +	report_info("stsch: flags: %04x", pmcw->flags);
> 
> It feels like all of this already should have been included in the
> previous patch?

Yes, I did not want to modify it since it was reviewed-by.

> 
>>   	if (pmcw->flags & PMCW_ENABLE) {
>>   		report_info("stsch: sch %08x enabled after %d retries",
>>   			    schid, retry_count);
>> @@ -129,3 +144,134 @@ retry:
>>   		    schid, retry_count, pmcw->flags);
>>   	return -1;
>>   }
>> +
>> +static struct irb irb;
>> +
>> +void css_irq_io(void)
>> +{
>> +	int ret = 0;
>> +	char *flags;
>> +	int sid;
>> +
>> +	report_prefix_push("Interrupt");
>> +	sid = lowcore_ptr->subsys_id_word;
>> +	/* Lowlevel set the SID as interrupt parameter. */
>> +	if (lowcore_ptr->io_int_param != sid) {
>> +		report(0,
>> +		       "io_int_param: %x differs from subsys_id_word: %x",
>> +		       lowcore_ptr->io_int_param, sid);
>> +		goto pop;
>> +	}
>> +	report_info("subsys_id_word: %08x io_int_param %08x io_int_word %08x",
>> +			lowcore_ptr->subsys_id_word,
>> +			lowcore_ptr->io_int_param,
>> +			lowcore_ptr->io_int_word);
>> +	report_prefix_pop();
>> +
>> +	report_prefix_push("tsch");
>> +	ret = tsch(sid, &irb);
>> +	switch (ret) {
>> +	case 1:
>> +		dump_irb(&irb);
>> +		flags = dump_scsw_flags(irb.scsw.ctrl);
>> +		report(0,
>> +		       "I/O interrupt, CC 1 but tsch reporting sch %08x as not status pending: %s",
> 
> "I/O interrupt, but tsch returns CC 1 for subchannel %08x" ?

Yes better, thanks

> 
>> +		       sid, flags);
>> +		break;
>> +	case 2:
>> +		report(0, "tsch returns unexpected CC 2");
>> +		break;
>> +	case 3:
>> +		report(0, "tsch reporting sch %08x as not operational", sid);
>> +		break;
>> +	case 0:
>> +		/* Stay humble on success */
>> +		break;
>> +	}
>> +pop:
>> +	report_prefix_pop();
>> +	lowcore_ptr->io_old_psw.mask &= ~PSW_MASK_WAIT;
>> +}
>> +
>> +int start_ccw1_chain(unsigned int sid, struct ccw1 *ccw)
>> +{
>> +	struct orb orb = {
>> +		.intparm = sid,
>> +		.ctrl = ORB_CTRL_ISIC|ORB_CTRL_FMT|ORB_LPM_DFLT,
>> +		.cpa = (unsigned int) (unsigned long)ccw,
>> +	};
>> +
>> +	return ssch(sid, &orb);
>> +}
>> +
>> +/*
>> + * In the future, we want to implement support for CCW chains;
>> + * for that, we will need to work with ccw1 pointers.
>> + */
>> +static struct ccw1 unique_ccw;
>> +
>> +int start_single_ccw(unsigned int sid, int code, void *data, int count,
>> +		     unsigned char flags)
>> +{
>> +	int cc;
>> +	struct ccw1 *ccw = &unique_ccw;
>> +
>> +	report_prefix_push("start_subchannel");
>> +	/* Build the CCW chain with a single CCW */
>> +	ccw->code = code;
>> +	ccw->flags = flags; /* No flags need to be set */
> 
> s/No flags/No additional flags/

obviously :)

> 
>> +	ccw->count = count;
>> +	ccw->data_address = (int)(unsigned long)data;
>> +
>> +	cc = start_ccw1_chain(sid, ccw);
>> +	if (cc) {
>> +		report(0, "start_ccw_chain failed ret=%d", cc);
>> +		report_prefix_pop();
>> +		return cc;
>> +	}
>> +	report_prefix_pop();
>> +	return 0;
>> +}
>> +
>> +/*
>> + * css_residual_count
>> + * We expect no residual count when the ORB request was successful
> 
> If we have a short block, but have suppressed the incorrect length
> indication, we may have a successful request with a nonzero count.
> Maybe replace this with "Return the residual count, if it is valid."?


OK

> 
>> + * The residual count is valid when the subchannel is status pending
>> + * with primary status and device status only or device status and
>> + * subchannel status with PCI or incorrect length.
>> + * Return value:
>> + * Success: the residual count
>> + * Not meaningful: -1 (-1 can not be a valid count)
>> + */
>> +int css_residual_count(unsigned int schid)
>> +{
>> +
>> +	if (!(irb.scsw.ctrl & (SCSW_SC_PENDING | SCSW_SC_PRIMARY)))
>> +		goto fail;
> 
> s/fail/invalid/ ? It's not really a failure :)

yes

> 
>> +
>> +	if (irb.scsw.dev_stat)
>> +		if (irb.scsw.sch_stat & ~(SCSW_SCHS_PCI | SCSW_SCHS_IL))
>> +			goto fail;
>> +
>> +	return irb.scsw.count;
>> +
>> +fail:
>> +	report_info("sch  status %02x", irb.scsw.sch_stat);
>> +	report_info("dev  status %02x", irb.scsw.dev_stat);
>> +	report_info("ctrl status %08x", irb.scsw.ctrl);
>> +	report_info("count       %04x", irb.scsw.count);
>> +	report_info("ccw addr    %08x", irb.scsw.ccw_addr);
> 
> I don't understand why you dump this data if no valid residual count is
> available. But maybe I don't understand the purpose of this function
> correctly.

As debug information to facilitate the search why the function failed.
Would you prefer more accurate report_info inside the if tests?
or just return with error code?

> 

>>   
>> +/*
>> + * test_sense
>> + * Pre-requisits:
> 
> s/Pre-requisists/Pre-requisites/

OK

> 
>> + * - We need the test device as the first recognized
>> + *   device by the enumeration.
>> + */
>> +static void test_sense(void)
>> +{
>> +	int ret;
>> +	int len;
>> +
>> +	if (!test_device_sid) {
>> +		report_skip("No device");
>> +		return;
>> +	}
>> +
>> +	ret = css_enable(test_device_sid, IO_SCH_ISC);
>> +	if (ret) {
>> +		report(0,
>> +		       "Could not enable the subchannel: %08x",
>> +		       test_device_sid);
>> +		return;
>> +	}
>> +
>> +	ret = register_io_int_func(css_irq_io);
>> +	if (ret) {
>> +		report(0, "Could not register IRQ handler");
>> +		goto unreg_cb;
>> +	}
>> +
>> +	lowcore_ptr->io_int_param = 0;
>> +
>> +	memset(&senseid, 0, sizeof(senseid));
>> +	ret = start_single_ccw(test_device_sid, CCW_CMD_SENSE_ID,
>> +			       &senseid, sizeof(senseid), CCW_F_SLI);
>> +	if (ret) {
>> +		report(0, "ssch failed for SENSE ID on sch %08x with cc %d",
>> +		       test_device_sid, ret);
>> +		goto unreg_cb;
>> +	}
>> +
>> +	wait_for_interrupt(PSW_MASK_IO);
>> +
>> +	if (lowcore_ptr->io_int_param != test_device_sid) {
>> +		report(0, "ssch succeeded but interrupt parameter is wrong: expect %08x got %08x",
>> +		       test_device_sid, lowcore_ptr->io_int_param);
>> +		goto unreg_cb;
>> +	}
>> +
>> +	ret = css_residual_count(test_device_sid);
>> +	if (ret < 0) {
>> +		report(0, "ssch succeeded for SENSE ID but can not get a valid residual count");
>> +		goto unreg_cb;
>> +	}
> 
> I'm not sure what you're testing here. You should first test whether
> the I/O concluded normally (i.e., whether you actually get something
> like status pending with channel end/device end). If not, it does not
> make much sense to look either at the residual count or at the sense id
> data.
> 
> If css_residual_count does not return something >= 0 for that 'normal'
> case, something is definitely fishy, though :)

I will add the test before the call to get the residual count.
May be it leads to rework the css_residual_count too.

> 
>> +
>> +	len = sizeof(senseid) - ret;
>> +	if (ret && len < CSS_SENSEID_COMMON_LEN) {
>> +		report(0,
>> +		       "ssch succeeded for SENSE ID but report a too short length: %d",
> 
> s/report/transferred/ ?

OK

> 
>> +		       ret);
>> +		goto unreg_cb;
>> +	}
>> +
>> +	if (ret && len)
>> +		report_info("ssch succeeded for SENSE ID but report a shorter length: %d",
> 
> Same here.

OK

snip...


Thanks for review.

Regards,
Pierre

-- 
Pierre Morel
IBM Lab Boeblingen

  reply	other threads:[~2020-07-06 13:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-02 16:31 [kvm-unit-tests PATCH v10 0/9] s390x: Testing the Channel Subsystem I/O Pierre Morel
2020-07-02 16:31 ` [kvm-unit-tests PATCH v10 1/9] s390x: saving regs for interrupts Pierre Morel
2020-07-02 16:31 ` [kvm-unit-tests PATCH v10 2/9] s390x: I/O interrupt registration Pierre Morel
2020-07-02 16:31 ` [kvm-unit-tests PATCH v10 3/9] s390x: export the clock get_clock_ms() utility Pierre Morel
2020-07-02 16:31 ` [kvm-unit-tests PATCH v10 4/9] s390x: clock and delays calculations Pierre Morel
2020-07-02 16:31 ` [kvm-unit-tests PATCH v10 5/9] s390x: define function to wait for interrupt Pierre Morel
2020-07-02 16:31 ` [kvm-unit-tests PATCH v10 6/9] s390x: Library resources for CSS tests Pierre Morel
2020-07-02 16:31 ` [kvm-unit-tests PATCH v10 7/9] s390x: css: stsch, enumeration test Pierre Morel
2020-07-02 16:31 ` [kvm-unit-tests PATCH v10 8/9] s390x: css: msch, enable test Pierre Morel
2020-07-02 16:31 ` [kvm-unit-tests PATCH v10 9/9] s390x: css: ssch/tsch with sense and interrupt Pierre Morel
2020-07-03  8:41   ` Thomas Huth
2020-07-03  9:05     ` Pierre Morel
2020-07-03 12:01       ` Janosch Frank
2020-07-03 12:25         ` Pierre Morel
2020-07-06  9:46   ` Cornelia Huck
2020-07-06 13:01     ` Pierre Morel [this message]
2020-07-06 14:24       ` Cornelia Huck
2020-07-07 10:57         ` Pierre Morel
2020-07-07 11:05           ` Cornelia Huck
2020-07-07 11:14             ` Pierre Morel

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=02eb7a70-7a74-6f09-334f-004e69aaa198@linux.ibm.com \
    --to=pmorel@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=drjones@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=thuth@redhat.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