All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: "Jason J. Herne" <jjherne@linux.ibm.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	pasic@linux.ibm.com, alifm@linux.ibm.com, borntraeger@de.ibm.com
Subject: Re: [Qemu-devel] [PATCH v3 10/16] s390-bios: Support for running format-0/1 channel programs
Date: Mon, 4 Mar 2019 19:25:22 +0100	[thread overview]
Message-ID: <20190304192522.138639d3.cohuck@redhat.com> (raw)
In-Reply-To: <1551466776-29123-11-git-send-email-jjherne@linux.ibm.com>

On Fri,  1 Mar 2019 13:59:30 -0500
"Jason J. Herne" <jjherne@linux.ibm.com> wrote:

> Add struct for format-0 ccws. Support executing format-0 channel
> programs and waiting for their completion before continuing execution.

That sentence is a bit confusing. What about:

"Introduce a library function for executing format-0 and format-1
channel programs..."

> This will be used for real dasd ipl.

But also for virtio in the follow-on patches, won't it?

> 
> 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      | 141 ++++++++++++++++++++++++++++++++++++++++++++
>  pc-bios/s390-ccw/cio.h      | 127 ++++++++++++++++++++++++++++++++++++++-
>  pc-bios/s390-ccw/s390-ccw.h |   1 +
>  pc-bios/s390-ccw/start.S    |  31 ++++++++++
>  4 files changed, 297 insertions(+), 3 deletions(-)
> 
(...)
> +/*
> + * Handles executing ssch, tsch and returns the irb obtained from tsch.
> + * Returns 0 on success, -1 if unexpected status pending and we need to retry,
> + * otherwse returns condition code from ssch/tsch for error cases.

s/otherwse/otherwise/

> + */
> +static int __do_cio(SubChannelId schid, uint32_t ccw_addr, int fmt, Irb *irb)
> +{
> +    CmdOrb orb = {};
> +    int rc;
> +
> +    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 ;

extra ' ' before ';'

> +    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;
> +
> +    rc = ssch(schid, &orb);
> +    if (rc == 1) {
> +        /* Status pending, not sure why. Eat status and ask for retry. */
> +        tsch(schid, irb);
> +        return -1;
> +    }
> +    if (rc) {
> +        print_int("ssch failed with rc=", rc);

Better 'cc' than 'rc' in the message?

> +        return rc;
> +    }
> +
> +    consume_io_int();
> +
> +    /* collect status */
> +    rc = tsch(schid, irb);
> +    if (rc) {
> +        print_int("tsch failed with rc=", rc);
> +    }

Hm. The whole code flow relies on the fact that not only no more than
one cpu is enabled for I/O interrupts, but also only one subchannel.
Otherwise, you could get an interrupt for another subchannel, which
would be the only way you'd get cc 1 on the tsch for this subchannel
here (no status pending). Maybe peek at the interruption information
stored into the lowcore first?

Won't be a problem with the code as it is now, though, AFAICS.

> +
> +    return rc;
> +}
> +
> +/*
> + * 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.
> + *
> + * Returns non-zero on error.
> + */
> +int do_cio(SubChannelId schid, uint32_t ccw_addr, int fmt)
> +{
> +    Irb irb = {};
> +    SenseDataEckdDasd sd;
> +    int rc, retries = 0;
> +
> +    while (true) {
> +        rc = __do_cio(schid, ccw_addr, fmt, &irb);
> +
> +        if (rc == -1) {
> +            retries++;
> +            continue;
> +        }
> +        if (rc) {
> +            /* ssch/tsch error. Message already reported by __do_cio */

You might also want to consider retrying on cc 2. Not very likely,
though.

> +            break;
> +        }
> +
> +        if (!irb_error(&irb)) {
> +            break;
> +        }
> +
> +        /*
> +         * Unexpected unit check, or interface-control-check. Use sense to
> +         * clear (unit check only) then retry.
> +         */
> +        if ((unit_check(&irb) || iface_ctrl_check(&irb)) && retries <= 2) {
> +            if (unit_check(&irb)) {
> +                basic_sense(schid, &sd, sizeof(sd));

Unless I'm confused: I think you can still descend into the unit check
rabbit hole here. basic_sense() calls do_cio(), which calls
basic_sense(),... and we don't even get to the retries check.

Maybe call __do_cio() from basic_sense() instead and make that return
an error instead of panicking? Then you could just bump retries here
and give up after some retries...

> +            }
> +            retries++;
> +            continue;
> +        }
> +
> +        rc = -1;
> +        break;
> +    }
> +
> +    return rc;
> +}

  reply	other threads:[~2019-03-04 18:25 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01 18:59 [Qemu-devel] [PATCH v3 00/16] s390: vfio-ccw dasd ipl support Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 01/16] s390 vfio-ccw: Add bootindex property and IPLB data Jason J. Herne
2019-03-04 13:40   ` Cornelia Huck
2019-03-06 14:55     ` Jason J. Herne
2019-03-06 15:27       ` Cornelia Huck
2019-03-06 16:28         ` Jason J. Herne
2019-03-06 17:31           ` Cornelia Huck
2019-03-04 16:09   ` Farhan Ali
2019-03-06 15:16     ` Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 02/16] s390-bios: decouple cio setup from virtio Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 03/16] s390-bios: decouple common boot logic " Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 04/16] s390-bios: Extend find_dev() for non-virtio devices Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 05/16] s390-bios: Factor finding boot device out of virtio code path Jason J. Herne
2019-03-04 17:07   ` Cornelia Huck
2019-03-04 19:26     ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-05  8:38       ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 06/16] s390-bios: Clean up cio.h Jason J. Herne
2019-03-04 17:23   ` Cornelia Huck
2019-03-05  5:51   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-06 18:42     ` Jason J. Herne
2019-03-07  8:08       ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 07/16] s390-bios: Decouple channel i/o logic from virtio Jason J. Herne
2019-03-04 17:28   ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 08/16] s390-bios: Map low core memory Jason J. Herne
2019-03-04 17:46   ` Cornelia Huck
2019-03-05  6:27   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-06 19:28     ` Jason J. Herne
2019-03-07  8:11       ` Cornelia Huck
2019-03-06 19:42     ` Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 09/16] s390-bios: ptr2u32 and u32toptr Jason J. Herne
2019-03-05  7:22   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-07 14:11     ` Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 10/16] s390-bios: Support for running format-0/1 channel programs Jason J. Herne
2019-03-04 18:25   ` Cornelia Huck [this message]
2019-03-07 19:25     ` Jason J. Herne
2019-03-08  9:19       ` Cornelia Huck
2019-03-05  7:32   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 11/16] s390-bios: cio error handling Jason J. Herne
2019-03-04 18:35   ` Cornelia Huck
2019-03-07 19:31     ` Jason J. Herne
2019-03-08  9:21       ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 12/16] s390-bios: Refactor virtio to run channel programs via cio Jason J. Herne
2019-03-05 12:30   ` Cornelia Huck
2019-03-07 15:09     ` Jason J. Herne
2019-03-07 15:37       ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 13/16] s390-bios: Use control unit type to determine boot method Jason J. Herne
2019-03-05 12:27   ` Cornelia Huck
2019-03-07 16:27     ` Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 14/16] s390-bios: Add channel command codes/structs needed for dasd-ipl Jason J. Herne
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 15/16] s390-bios: Support booting from real dasd device Jason J. Herne
2019-03-05 13:03   ` Cornelia Huck
2019-03-01 18:59 ` [Qemu-devel] [PATCH v3 16/16] s390-bios: dasd-ipl: Use control unit type to customize error data Jason J. Herne
2019-03-04 17:02   ` [Qemu-devel] [qemu-s390x] " Eric Farman
2019-03-07 14:38     ` Jason J. Herne
2019-03-07 18:15       ` Eric Farman
2019-03-07 18:26         ` Jason J. Herne
2019-03-04 17:51   ` [Qemu-devel] " Cornelia Huck
2019-03-01 21:26 ` [Qemu-devel] [PATCH v3 00/16] s390: vfio-ccw dasd ipl support no-reply
2019-03-01 21:30 ` no-reply
2019-03-01 21:35 ` no-reply
2019-03-01 21:38 ` no-reply
2019-03-01 21:45 ` no-reply
2019-03-01 21:49 ` no-reply
2019-03-04 16:24 ` Cornelia Huck
2019-03-04 17:53   ` Christian Borntraeger
2019-03-04 17:28 ` no-reply
2019-03-04 17:51 ` no-reply
2019-03-05  5:55 ` no-reply
2019-03-05  7:30 ` no-reply
2019-03-05  8:42 ` no-reply
2019-03-05 13:08 ` no-reply

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=20190304192522.138639d3.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.