aboutsummaryrefslogtreecommitdiff
path: root/hw/vfio
diff options
context:
space:
mode:
authorCornelia Huck <cohuck@redhat.com>2021-07-05 18:39:51 +0200
committerThomas Huth <thuth@redhat.com>2021-09-06 16:22:54 +0200
commit759a5d3be0ca447514bc774f97218d3a0a8ed654 (patch)
tree3922636928c9e7c2fecc99bd345a0c84d8e72300 /hw/vfio
parent935efca6c246c108253b0e4e51cc87648fc7ca10 (diff)
downloadqemu-759a5d3be0ca447514bc774f97218d3a0a8ed654.zip
qemu-759a5d3be0ca447514bc774f97218d3a0a8ed654.tar.gz
qemu-759a5d3be0ca447514bc774f97218d3a0a8ed654.tar.bz2
vfio-ccw: forward halt/clear errors
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>
Diffstat (limited to 'hw/vfio')
-rw-r--r--hw/vfio/ccw.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index 000992f..0354737 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -199,7 +199,7 @@ again:
case 0:
case -ENODEV:
case -EACCES:
- return 0;
+ return ret;
case -EFAULT:
default:
sch_gen_unit_exception(sch);
@@ -240,7 +240,7 @@ again:
case -EBUSY:
case -ENODEV:
case -EACCES:
- return 0;
+ return ret;
case -EFAULT:
default:
sch_gen_unit_exception(sch);