* Re: [Qemu-devel] [0/3] vfio-ccw: support hsch/csch (kernel part)
[not found] <45f67421-f26d-a5e5-d388-de65e6cc26ec@linux.ibm.com>
@ 2018-12-06 12:34 ` Cornelia Huck
0 siblings, 0 replies; only message in thread
From: Cornelia Huck @ 2018-12-06 12:34 UTC (permalink / raw)
To: Jason J. Herne
Cc: Halil Pasic, Farhan Ali, qemu-s390x, linux-s390, Eric Farman,
Alex Williamson, Pierre Morel, kvm, qemu-devel
On Wed, 5 Dec 2018 13:08:56 -0500
"Jason J. Herne" <jjherne@linux.ibm.com> wrote:
> Connie,
>
> Sorry if this does not thread nicely. I never received the original (Thunderbird
> corruption/hangs) so I had to fake it :).
I hopefully managed to restore the rest of the cc:s :)
>
> >> My point is, when the subchannel is disabled, 'firmware' is responsible
> >> for suppressing interrupts and error conditions, and also for
> >> doing the appropriate recovery procedure, so to say under the hood.
> >
> > I don't think there's actually much of a 'recovery' possible at a
> > subchannel level (other than 'have you tried turning it off and on
> > again?'); the interesting stuff is all at the device-specific level.
> >
> >> I think Jason has discovered some problems related to this while doing
> >> his DASD IPL with vfio-ccw work, but I don't quite remember any more.
> >
> > cc:ing Jason, in case he remembers :)
>
> Here is what Halil was talking about.
> I'm seeing a problem during kvm on z development of vfio-ccw (passthrough dasd).
> After a fresh IPL of the host system, sometimes my first channel program
> executed on my vfio-ccw device generates a unit check. The sense data given for
> that unit check indicates that a reset event has occurred. This is apparently
> normal to see after a device, channel or subsystem reset.
Sounds reasonable.
> I'm trying to figure out how to deal with this unit check in the vfio-ccw kernel
> driver. The thinking at the moment is to just retry any i/o operation a limited
> number of times after any unit check, then give up if the i/o operation still
> does not succeed. The kernel apparently uses a similar approach for the regular
> dasd driver.
Is that unit check in response to a channel program submitted by the
guest? If yes, I think that the unit check should be reflected back to
the guest as well in that case. We should only keep the unit check to
ourselves if it was triggered by something internally.
[On a tangent: Do current dasds actually support concurrent sense, or
do you still need to collect the sense data via a sense ccw after a
unit check?]
^ permalink raw reply [flat|nested] only message in thread