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, bjsdjshi@linux.ibm.com,
	borntraeger@de.ibm.com
Subject: Re: [Qemu-devel] [RFC 15/15] s390-bios: Use sense ccw to ensure consistent device state at boot time
Date: Fri, 6 Jul 2018 12:08:41 +0200	[thread overview]
Message-ID: <20180706120841.11cbdfa8.cohuck@redhat.com> (raw)
In-Reply-To: <1530811543-6881-16-git-send-email-jjherne@linux.ibm.com>

On Thu,  5 Jul 2018 13:25:43 -0400
"Jason J. Herne" <jjherne@linux.ibm.com> wrote:

> If a vfio-ccw device is left in an error state (example: pending unit
> check) then it is possible for that state to persist for a vfio-ccw device even
> after the enable subchannel that we do to bring the device online. If this state
> is allowed to persist then even simple I/O operations will needlessly fail. A
> basic sense ccw is used to clear this error state for the boot device.

Another thing: What about unsolicited interrupts? I.e., you enable the
subchannel, and then it becomes pending with unsolicited status. Do you
have any handling for that (or plan to add it)?

We could ignore that for virtio devices, but probably not for dasds.

> 
> Signed-off-by: Jason J. Herne <jjherne@linux.ibm.com>
> ---
>  pc-bios/s390-ccw/cio.c  | 13 +++++++++++++
>  pc-bios/s390-ccw/cio.h  | 13 +++++++++++++
>  pc-bios/s390-ccw/main.c |  5 +++++
>  3 files changed, 31 insertions(+)

> diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
> index 2bccfa7..e0ce59b 100644
> --- a/pc-bios/s390-ccw/main.c
> +++ b/pc-bios/s390-ccw/main.c
> @@ -201,12 +201,17 @@ static void virtio_setup(void)
>  
>  int main(void)
>  {
> +    SenseData sd;
> +
>      sclp_setup();
>      cio_setup();
>      boot_setup();
>      find_boot_device();
>      enable_subchannel(blk_schid);
>  
> +    /* Clear any outstanding device error conditions */
> +    basic_sense(blk_schid, &sd);

Hmm. Could an error condition reassert itself after it was cleared?
Probably not worth spending too much time on, though.

> +
>      switch (cu_type(blk_schid)) {
>      case 0x3990:  /* Real DASD device */
>          dasd_ipl(blk_schid); /* no return */

  reply	other threads:[~2018-07-06 10:08 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-05 17:25 [Qemu-devel] [RFC 00/15] s390: vfio-ccw dasd ipl support Jason J. Herne
2018-07-05 17:25 ` [Qemu-devel] [RFC 01/15] s390 vfio-ccw: Add bootindex property and IPLB data Jason J. Herne
2018-07-06  7:33   ` Cornelia Huck
2018-07-11 10:33   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2018-07-05 17:25 ` [Qemu-devel] [RFC 02/15] s390-bios: decouple cio setup from virtio Jason J. Herne
2018-07-06  7:35   ` Cornelia Huck
2018-07-05 17:25 ` [Qemu-devel] [RFC 03/15] s390-bios: decouple common boot logic " Jason J. Herne
2018-07-11 10:41   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2018-07-05 17:25 ` [Qemu-devel] [RFC 04/15] s390-bios: Extend find_dev() for non-virtio devices Jason J. Herne
2018-07-05 17:25 ` [Qemu-devel] [RFC 05/15] s390-bios: Factor finding boot device out of virtio code path Jason J. Herne
2018-07-10  6:53   ` Christian Borntraeger
2018-07-05 17:25 ` [Qemu-devel] [RFC 06/15] s390-bios: Clean up cio.h Jason J. Herne
2018-07-17 18:15   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2018-07-17 18:22     ` Richard Henderson
2018-07-05 17:25 ` [Qemu-devel] [RFC 07/15] s390-bios: Decouple channel i/o logic from virtio Jason J. Herne
2018-07-06  6:48   ` Christian Borntraeger
2018-07-05 17:25 ` [Qemu-devel] [RFC 08/15] s390-bios: Map low core memory Jason J. Herne
2018-07-06  6:46   ` Christian Borntraeger
2018-07-06  7:42   ` Cornelia Huck
2018-07-17 18:10   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2018-09-10 14:17     ` Jason J. Herne
2018-09-13  5:25       ` Thomas Huth
2018-09-13 14:39         ` Jason J. Herne
2018-07-05 17:25 ` [Qemu-devel] [RFC 09/15] s390-bios: ptr2u32 and u32toptr Jason J. Herne
2018-07-05 17:25 ` [Qemu-devel] [RFC 10/15] s390-bios: Support for running format-0/1 channel programs Jason J. Herne
2018-07-06  7:04   ` Christian Borntraeger
2018-07-06 10:25     ` [Qemu-devel] [qemu-s390x] " Christian Borntraeger
2018-07-06  8:03   ` [Qemu-devel] " Cornelia Huck
2018-07-06 11:42     ` [Qemu-devel] [qemu-s390x] " Halil Pasic
2018-07-06 12:26       ` Cornelia Huck
2018-07-06 13:03         ` Halil Pasic
2018-07-06 13:15           ` Cornelia Huck
2018-07-06 13:33             ` Halil Pasic
2018-07-06 14:40               ` Jason J. Herne
2018-07-06 14:35     ` [Qemu-devel] " Jason J. Herne
2018-07-17 10:02       ` Cornelia Huck
2018-07-09  7:18   ` Christian Borntraeger
2018-07-09 10:51   ` Christian Borntraeger
2018-07-05 17:25 ` [Qemu-devel] [RFC 11/15] s390-bios: Refactor virtio to run channel programs via cio Jason J. Herne
2018-07-05 17:25 ` [Qemu-devel] [RFC 12/15] s390-bios: Use control unit type to determine boot method Jason J. Herne
2018-07-17 18:25   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2018-07-05 17:25 ` [Qemu-devel] [RFC 13/15] s390-bios: Add channel command codes/structs needed for dasd-ipl Jason J. Herne
2018-07-05 17:25 ` [Qemu-devel] [RFC 14/15] s390-bios: Support booting from real dasd device Jason J. Herne
2018-07-17 20:43   ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2018-07-18  7:40     ` Cornelia Huck
2018-07-18  7:51       ` David Hildenbrand
2018-07-18 10:55       ` Halil Pasic
2018-07-18 11:35         ` Cornelia Huck
2018-07-18 11:47           ` Halil Pasic
2018-07-18 11:44   ` [Qemu-devel] " Halil Pasic
2018-07-05 17:25 ` [Qemu-devel] [RFC 15/15] s390-bios: Use sense ccw to ensure consistent device state at boot time Jason J. Herne
2018-07-06 10:08   ` Cornelia Huck [this message]
2018-07-06 14:45     ` Jason J. Herne
2018-07-06 22:20   ` Halil Pasic
2018-07-05 18:32 ` [Qemu-devel] [RFC 00/15] s390: vfio-ccw dasd ipl support no-reply
2018-07-06  6:42 ` Cornelia Huck
2018-08-15 11:48 ` Cornelia Huck
2018-08-21 19:31   ` Jason J. Herne
2018-08-22  7:46     ` 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=20180706120841.11cbdfa8.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=bjsdjshi@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.