248b920df9
The architecture says that channel-data check is indicating that an uncorrected storage (memory) error has been detected in regard to the data residing in main storage (memory) that is currently used for an I/O operation. The described detection is done using the CBC technology. The ccw interpretation code is however generating a channel-data check effectively when the (device specific) ccw_cb returns -EFAULT. In case of virtio-ccw devices this happens when mapping memory fails, or when a NULL pointer is encountered. So this behavior is not architecture conform. Furthermore the best fit for these situations (null pointer, mapping a piece of guest memory fails) from architectural perspective the condition described as the channel subsystem refers to a location that is not available, which when encountered shall result in a channel-program check. To fix this, all we have to do is to get rid of the switch case matching -EFAULT: the default is generating a channel-program check. Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20170908152446.14606-2-pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> |
||
---|---|---|
.. | ||
3270-ccw.c | ||
ccw-device.c | ||
ccw-device.h | ||
css-bridge.c | ||
css.c | ||
event-facility.c | ||
ipl.c | ||
ipl.h | ||
Makefile.objs | ||
s390-ccw.c | ||
s390-pci-bus.c | ||
s390-pci-bus.h | ||
s390-pci-inst.c | ||
s390-pci-inst.h | ||
s390-pci-stub.c | ||
s390-skeys-kvm.c | ||
s390-skeys.c | ||
s390-stattrib-kvm.c | ||
s390-stattrib.c | ||
s390-virtio-ccw.c | ||
s390-virtio-hcall.c | ||
s390-virtio.c | ||
s390-virtio.h | ||
sclp.c | ||
sclpcpu.c | ||
sclpquiesce.c | ||
trace-events | ||
virtio-ccw.c | ||
virtio-ccw.h |