[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 15/15] s390-bios: Use sense ccw to ensure consiste
From: |
Halil Pasic |
Subject: |
Re: [Qemu-devel] [RFC 15/15] s390-bios: Use sense ccw to ensure consistent device state at boot time |
Date: |
Sat, 7 Jul 2018 00:20:47 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 07/05/2018 07:25 PM, Jason J. Herne 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.
Signed-off-by: Jason J. Herne<address@hidden>
I don't like this. AFAIK an IPL is preceded by and subsystem reset. If
it weren't the IPL-ed OS (program) would have to take care any potential
mess left by the previous one -- and pray it gets control. A subsystem
reset should clear any device error state, so it is not supposed to
persist across subsystem resets. If the error re-emerges (unsolicited)
after the reset, it's likely something is really broken and needs investigation.
Generally IPL is supposed to fail in such cases (except for corner cases
which are not really handled by this patch).
AFAIU this patch works around a broken reset. While our bios is not guest and
one could try to argue that it's firmware -- part of 'the machine', a believe
handling the reset in the bios is wrong. AFAIR the qemu emulator is in charge,
and if needed makes kvm do what it has to.
If the reset is broken for vfio-ccw (which is very possible, but I would have
to check), I think we should fix it in the right place. A workaround may be
still justified (if kernel changes like clear support are needed). But we
should indicate that clearly in the commit message and in the code.
Regards,
Halil
- Re: [Qemu-devel] [RFC 10/15] s390-bios: Support for running format-0/1 channel programs, (continued)
Re: [Qemu-devel] [RFC 10/15] s390-bios: Support for running format-0/1 channel programs, Christian Borntraeger, 2018/07/09
Re: [Qemu-devel] [RFC 10/15] s390-bios: Support for running format-0/1 channel programs, Christian Borntraeger, 2018/07/09
[Qemu-devel] [RFC 04/15] s390-bios: Extend find_dev() for non-virtio devices, Jason J. Herne, 2018/07/05
[Qemu-devel] [RFC 13/15] s390-bios: Add channel command codes/structs needed for dasd-ipl, Jason J. Herne, 2018/07/05
[Qemu-devel] [RFC 09/15] s390-bios: ptr2u32 and u32toptr, Jason J. Herne, 2018/07/05
[Qemu-devel] [RFC 15/15] s390-bios: Use sense ccw to ensure consistent device state at boot time, Jason J. Herne, 2018/07/05
[Qemu-devel] [RFC 05/15] s390-bios: Factor finding boot device out of virtio code path, Jason J. Herne, 2018/07/05
[Qemu-devel] [RFC 12/15] s390-bios: Use control unit type to determine boot method, Jason J. Herne, 2018/07/05
[Qemu-devel] [RFC 02/15] s390-bios: decouple cio setup from virtio, Jason J. Herne, 2018/07/05
[Qemu-devel] [RFC 11/15] s390-bios: Refactor virtio to run channel programs via cio, Jason J. Herne, 2018/07/05
[Qemu-devel] [RFC 03/15] s390-bios: decouple common boot logic from virtio, Jason J. Herne, 2018/07/05
[Qemu-devel] [RFC 07/15] s390-bios: Decouple channel i/o logic from virtio, Jason J. Herne, 2018/07/05