[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [0/3] vfio-ccw: support hsch/csch (kernel part)
From: |
Jason J. Herne |
Subject: |
Re: [qemu-s390x] [0/3] vfio-ccw: support hsch/csch (kernel part) |
Date: |
Wed, 5 Dec 2018 13:08:56 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
Connie,
Sorry if this does not thread nicely. I never received the original (Thunderbird
corruption/hangs) so I had to fake it :).
>> 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.
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.
--
-- Jason J. Herne (address@hidden)
- Re: [qemu-s390x] [0/3] vfio-ccw: support hsch/csch (kernel part),
Jason J. Herne <=