On 07/06/2018 03:15 PM, Cornelia Huck wrote:
On Fri, 6 Jul 2018 15:03:49 +0200
Halil Pasic <pa...@linux.ibm.com> wrote:
On 07/06/2018 02:26 PM, Cornelia Huck wrote:
On Fri, 6 Jul 2018 13:42:25 +0200
Halil Pasic <pa...@linux.ibm.com> wrote:
On 07/06/2018 10:03 AM, Cornelia Huck wrote:
On Thu, 5 Jul 2018 13:25:38 -0400
"Jason J. Herne" <jjhe...@linux.ibm.com> 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.
Regards,
Halil