qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Farhan Ali <alifm@linux.ibm.com>
Cc: "Jason J. Herne" <jjherne@linux.ibm.com>,
	qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	pasic@linux.ibm.com, borntraeger@de.ibm.com
Subject: Re: [Qemu-devel] [PATCH 10/15] s390-bios: Support for running format-0/1 channel programs
Date: Mon, 4 Feb 2019 12:13:19 +0100	[thread overview]
Message-ID: <20190204121319.32915fd6.cohuck@redhat.com> (raw)
In-Reply-To: <735ca9ff-76e3-966f-6fbc-a72bf994b413@linux.ibm.com>

On Thu, 31 Jan 2019 12:31:00 -0500
Farhan Ali <alifm@linux.ibm.com> wrote:

> On 01/29/2019 08:29 AM, Jason J. Herne wrote:
> > Add struct for format-0 ccws. Support executing format-0 channel
> > programs and waiting for their completion before continuing execution.
> > This will be used for real dasd ipl.
> > 
> > Add cu_type() to channel io library. This will be used to query control
> > unit type which is used to determine if we are booting a virtio device or a
> > real dasd device.
> > 
> > Signed-off-by: Jason J. Herne<jjherne@linux.ibm.com>
> > ---
> >   pc-bios/s390-ccw/cio.c      | 114 +++++++++++++++++++++++++++++++++++++++
> >   pc-bios/s390-ccw/cio.h      | 127 ++++++++++++++++++++++++++++++++++++++++++--
> >   pc-bios/s390-ccw/s390-ccw.h |   1 +
> >   pc-bios/s390-ccw/start.S    |  33 +++++++++++-
> >   4 files changed, 270 insertions(+), 5 deletions(-)

> > +/*
> > + * Executes a channel program at a given subchannel. The request to run the
> > + * channel program is sent to the subchannel, we then wait for the interrupt
> > + * signaling completion of the I/O operation(s) performed by the channel
> > + * program. Lastly we verify that the i/o operation completed without error and
> > + * that the interrupt we received was for the subchannel used to run the
> > + * channel program.
> > + *
> > + * Note: This function assumes it is running in an environment where no other
> > + * cpus are generating or receiving I/O interrupts. So either run it in a
> > + * single-cpu environment or make sure all other cpus are not doing I/O and
> > + * have I/O interrupts masked off.
> > + */
> > +int do_cio(SubChannelId schid, uint32_t ccw_addr, int fmt)
> > +{
> > +    CmdOrb orb = {};
> > +    Irb irb = {};
> > +    sense_data_eckd_dasd sd;
> > +    int rc, retries = 0;
> > +
> > +    IPL_assert(fmt == 0 || fmt == 1, "Invalid ccw format");
> > +
> > +    /* ccw_addr must be <= 24 bits and point to at least one whole ccw. */
> > +    if (fmt == 0) {
> > +        IPL_assert(ccw_addr <= 0xFFFFFF - 8, "Invalid ccw address");
> > +    }
> > +
> > +    orb.fmt = fmt ;
> > +    orb.pfch = 1;  /* QEMU's cio implementation requires prefetch */
> > +    orb.c64 = 1;   /* QEMU's cio implementation requires 64-bit idaws */
> > +    orb.lpm = 0xFF; /* All paths allowed */
> > +    orb.cpa = ccw_addr;
> > +
> > +    while (true) {
> > +        rc = ssch(schid, &orb);
> > +        if (rc == 1) {
> > +            /* Status pending, not sure why. Let's eat the status and retry. */
> > +            tsch(schid, &irb);
> > +            retries++;
> > +            continue;
> > +        }
> > +        if (rc) {
> > +            print_int("ssch failed with rc=", rc);
> > +            break;
> > +        }
> > +
> > +        consume_io_int();
> > +
> > +        /* collect status */
> > +        rc = tsch(schid, &irb);
> > +        if (rc) {
> > +            print_int("tsch failed with rc=", rc);
> > +            break;
> > +        }
> > +
> > +        if (!irb_error(&irb)) {
> > +            break;
> > +        }
> > +
> > +        /*
> > +         * Unexpected unit check, or interface-control-check. Use sense to
> > +         * clear unit check then retry.
> > +         */
> > +        if ((unit_check(&irb) || iface_ctrl_check(&irb)) && retries <= 2) {
> > +            basic_sense(schid, &sd, sizeof(sd));  
> 
> We are using basic sense to clear any unit check or ifcc, but is it 
> possible for the basic sense to cause another unit check?
> 
> The chapter on Basic Sense in the Common I/O Device Commands 
> (http://publibz.boulder.ibm.com/support/libraryserver/FRAMESET/dz9ar501/2.1?SHELF=&DT=19920409154647&CASE=) 
>   says this:
> 
> ""
> The basic sense command initiates a sense operation  at  all  devices 
> and cannot  cause  the  command-reject,  intervention-required, 
> data-check, or overrun bit to be set to one.  If the control unit 
> detects  an  equipment malfunction  or  invalid  checking-block  code 
> (CBC) on the sense-command code, the equipment-check or bus-out-check 
> bit is set  to  one,  and  unit check is indicated in the device-status 
> byte.
> ""
> 
> If my understanding is correct, if there is an equipment malfunction 
> then the control unit can return a unit check even for a basic sense. 
> This can lead to infinite recursion in the bios.

I think the retries variable is supposed to take care of that.

What I don't understand is why we do the basic sense after an IFCC?
Wouldn't it make more sense to simply retry the original command in
that case?

> 
> 
> 
> > +            retries++;
> > +            continue;
> > +        }
> > +
> > +        break;
> > +    }
> > +
> > +    return rc;
> > +}  
> 

  reply	other threads:[~2019-02-04 11:28 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-29 13:29 [Qemu-devel] [PATCH 00/15] s390: vfio-ccw dasd ipl support Jason J. Herne
2019-01-29 13:29 ` [Qemu-devel] [PATCH 01/15] s390 vfio-ccw: Add bootindex property and IPLB data Jason J. Herne
2019-01-30 16:56   ` Cornelia Huck
2019-01-30 20:12     ` Jason J. Herne
2019-01-30 22:21   ` Farhan Ali
2019-02-08 16:07     ` Jason J. Herne
2019-01-31 18:20   ` Cornelia Huck
2019-02-04 10:26   ` Cornelia Huck
2019-02-13 13:41     ` Jason J. Herne
2019-02-13 14:52       ` Cornelia Huck
2019-02-06 11:30   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-02-08 16:04     ` Jason J. Herne
2019-02-11  8:15       ` Cornelia Huck
2019-02-11  8:39       ` Thomas Huth
2019-01-29 13:29 ` [Qemu-devel] [PATCH 02/15] s390-bios: decouple cio setup from virtio Jason J. Herne
2019-01-30 22:23   ` Farhan Ali
2019-02-04 10:28   ` Cornelia Huck
2019-02-05  9:55   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-01-29 13:29 ` [Qemu-devel] [PATCH 03/15] s390-bios: decouple common boot logic " Jason J. Herne
2019-01-30 22:27   ` Farhan Ali
2019-02-04 10:31   ` Cornelia Huck
2019-01-29 13:29 ` [Qemu-devel] [PATCH 04/15] s390-bios: Extend find_dev() for non-virtio devices Jason J. Herne
2019-02-04 10:33   ` Cornelia Huck
2019-02-11 16:38   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-02-13 13:59     ` Jason J. Herne
2019-03-04 19:23       ` Thomas Huth
2019-01-29 13:29 ` [Qemu-devel] [PATCH 05/15] s390-bios: Factor finding boot device out of virtio code path Jason J. Herne
2019-01-31 13:44   ` Farhan Ali
2019-02-04 10:45   ` Cornelia Huck
2019-02-11 17:57     ` Jason J. Herne
2019-02-12  9:32       ` Cornelia Huck
2019-01-29 13:29 ` [Qemu-devel] [PATCH 06/15] s390-bios: Clean up cio.h Jason J. Herne
2019-01-31 14:23   ` Farhan Ali
2019-02-04 10:48   ` Cornelia Huck
2019-02-12 12:32     ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-01-29 13:29 ` [Qemu-devel] [PATCH 07/15] s390-bios: Decouple channel i/o logic from virtio Jason J. Herne
2019-01-31 14:38   ` Farhan Ali
2019-01-31 14:45     ` Jason J. Herne
2019-02-04 10:57   ` Cornelia Huck
2019-02-13 14:40     ` Jason J. Herne
2019-01-29 13:29 ` [Qemu-devel] [PATCH 08/15] s390-bios: Map low core memory Jason J. Herne
2019-02-12 12:47   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-02-18 15:40     ` Jason J. Herne
2019-02-18 15:49       ` Cornelia Huck
2019-02-18 16:52       ` Thomas Huth
2019-01-29 13:29 ` [Qemu-devel] [PATCH 09/15] s390-bios: ptr2u32 and u32toptr Jason J. Herne
2019-02-04 11:03   ` Cornelia Huck
2019-02-12 12:50   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-01-29 13:29 ` [Qemu-devel] [PATCH 10/15] s390-bios: Support for running format-0/1 channel programs Jason J. Herne
2019-01-31 17:31   ` Farhan Ali
2019-02-04 11:13     ` Cornelia Huck [this message]
2019-02-04 19:29       ` Farhan Ali
2019-02-05 10:18         ` Cornelia Huck
2019-02-12 13:10           ` Halil Pasic
2019-02-27 13:35           ` Jason J. Herne
2019-02-27 14:07             ` Cornelia Huck
2019-02-27 13:32       ` Jason J. Herne
2019-02-27 14:06         ` Cornelia Huck
2019-02-04 11:24   ` Cornelia Huck
2019-02-21 18:01     ` Jason J. Herne
2019-02-22  8:35       ` Cornelia Huck
2019-01-29 13:29 ` [Qemu-devel] [PATCH 11/15] s390-bios: cio error handling Jason J. Herne
2019-02-04 11:41   ` Cornelia Huck
2019-02-28 15:59     ` Jason J. Herne
2019-02-28 16:11       ` Cornelia Huck
2019-01-29 13:29 ` [Qemu-devel] [PATCH 12/15] s390-bios: Refactor virtio to run channel programs via cio Jason J. Herne
2019-02-04 11:44   ` Cornelia Huck
2019-02-25 13:20     ` Jason J. Herne
2019-02-25 17:07       ` Cornelia Huck
2019-01-29 13:29 ` [Qemu-devel] [PATCH 13/15] s390-bios: Use control unit type to determine boot method Jason J. Herne
2019-02-04 11:46   ` Cornelia Huck
2019-01-29 13:29 ` [Qemu-devel] [PATCH 14/15] s390-bios: Add channel command codes/structs needed for dasd-ipl Jason J. Herne
2019-02-04 11:47   ` Cornelia Huck
2019-01-29 13:29 ` [Qemu-devel] [PATCH 15/15] s390-bios: Support booting from real dasd device Jason J. Herne
2019-01-31 18:23   ` Cornelia Huck
2019-02-04 12:02   ` Cornelia Huck
2019-02-19 14:57     ` Jason J. Herne
2019-02-21  2:52   ` [Qemu-devel] [qemu-s390x] " Eric Farman
2019-02-21 13:22     ` Jason J. Herne
2019-01-29 16:40 ` [Qemu-devel] [qemu-s390x] [PATCH 00/15] s390: vfio-ccw dasd ipl support Jason J. Herne
2019-01-31 18:10 ` [Qemu-devel] " no-reply
  -- strict thread matches above, loose matches on Subject: below --
2018-12-12 14:11 Jason J. Herne
2018-12-12 14:11 ` [Qemu-devel] [PATCH 10/15] s390-bios: Support for running format-0/1 channel programs Jason J. Herne
2018-12-13 16:54   ` Farhan Ali
2018-12-13 17:21   ` Cornelia Huck
2019-01-07 19:02     ` Jason J. Herne
2019-01-08 11:07       ` Cornelia Huck

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=20190204121319.32915fd6.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alifm@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    /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;
as well as URLs for NNTP newsgroup(s).