[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [Qemu-devel] [RFC 10/15] s390-bios: Support for running

From: Jason J. Herne
Subject: Re: [qemu-s390x] [Qemu-devel] [RFC 10/15] s390-bios: Support for running format-0/1 channel programs
Date: Fri, 6 Jul 2018 10:40:26 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 07/06/2018 09:33 AM, Halil Pasic wrote:

On 07/06/2018 03:15 PM, Cornelia Huck wrote:
On Fri, 6 Jul 2018 15:03:49 +0200
Halil Pasic <address@hidden> wrote:

On 07/06/2018 02:26 PM, Cornelia Huck wrote:
On Fri, 6 Jul 2018 13:42:25 +0200
Halil Pasic <address@hidden> wrote:
On 07/06/2018 10:03 AM, Cornelia Huck wrote:
On Thu,  5 Jul 2018 13:25:38 -0400
"Jason J. Herne" <address@hidden> wrote:
+    rc = ssch(schid, &orb);
+    if (rc) {
+        print_int("ssch failed with rc=", rc);

One nit: make this 'cc' instead of 'rc'?

+        return rc;

Are you doing anything like retrying on cc 1/2? It's probably fine to
give up on cc 3.

We are in IPL context. We should have exclusive access to the DASD
we are IPL-ing from, or not? My understanding was that if the layers
below us don't violate the rules, we should never observe cc 1 or 2
here. Or am I wrong?

cc 2 probably not (nobody should be doing a halt or a clear), but cc 1
if there's some unsolicited status pending?

AFAIK we are supposed to give up then. The status was supposed to be
cleared away on the reset which precedes IPL. If the device presented
an unsolicited status between reset and starting the IPL IO on the
channel I think the IPL should fail.

I very dimly remember efforts to make (non-QEMU) IPL more robust, but I
think that was more about IFCCs and the like.

Anyway, it is probably not worth spending too much time on. Being able
to IPL from vfio-ccw handled dasd is already very nice :)

PoP does not say much, and the internal documentation is, well internal.
Maybe we could do more on IFCC but we don't have to. One other thing
where we could do more is diagnostic info. But I really think this is
good enough for the first shot.

My thought was similar to what Halil says. We just cleared any unsolicited status. If that condition persists or we hit some crazy timing window where device characteristics have changed then we likely should re-drive the whole process anyway.

Also, given that this is a vfio-ccw device I suspect we are far enough isolated from the "real" device that the host kernel will handle those unsolicited interrupts and we won't ever see them. Can anyone confirm or deny that?

For IPL, I kind of feel this is not worth worrying about because the window is very small and it is only a very temporary problem for IPL (a one-shot operation). Feel free to disagree :)

-- Jason J. Herne (address@hidden)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]