759a5d3be0
hsch and csch basically have two parts: execute the command, and perform the halt/clear function. For fully emulated subchannels, it is pretty clear how it will work: check the subchannel state, and actually 'perform the halt/clear function' and set cc 0 if everything looks good. For passthrough subchannels, some of the checking is done within QEMU, but some has to be done within the kernel. QEMU's subchannel state may be such that we can perform the async function, but the kernel may still get a cc != 0 when it is actually executing the instruction. In that case, we need to set the condition actually encountered by the kernel; if we set cc 0 on error, we would actually need to inject an interrupt as well. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Tested-by: Jared Rossi <jrossi@linux.ibm.com> Message-Id: <20210705163952.736020-2-cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> |
||
---|---|---|
.. | ||
amd-xgbe.c | ||
ap.c | ||
calxeda-xgmac.c | ||
ccw.c | ||
common.c | ||
display.c | ||
igd.c | ||
Kconfig | ||
meson.build | ||
migration.c | ||
pci-quirks.c | ||
pci.c | ||
pci.h | ||
platform.c | ||
spapr.c | ||
trace-events | ||
trace.h |