aboutsummaryrefslogtreecommitdiff
path: root/gdbstub.c
diff options
context:
space:
mode:
authorDaniel P. Berrange <berrange@redhat.com>2016-09-06 14:56:04 +0100
committerPaolo Bonzini <pbonzini@redhat.com>2016-09-13 19:09:42 +0200
commit6ab3fc32ea640026726bc5f9f4db622d0954fb8a (patch)
tree8a48b6bb8d9746936bfc5cf8119e95f68b8f694a /gdbstub.c
parent7983e829336f68b6df6952dd4b03493b1486fcf5 (diff)
downloadqemu-6ab3fc32ea640026726bc5f9f4db622d0954fb8a.zip
qemu-6ab3fc32ea640026726bc5f9f4db622d0954fb8a.tar.gz
qemu-6ab3fc32ea640026726bc5f9f4db622d0954fb8a.tar.bz2
hw: replace most use of qemu_chr_fe_write with qemu_chr_fe_write_all
The qemu_chr_fe_write method will return -1 on EAGAIN if the chardev backend write would block. Almost no callers of the qemu_chr_fe_write() method check the return value, instead blindly assuming data was successfully sent. In most cases this will lead to silent data loss on interactive consoles, but in some cases (eg RNG EGD) it'll just cause corruption of the protocol being spoken. We unfortunately can't fix the virtio-console code, due to a bug in the Linux guest drivers, which would cause the entire Linux kernel to hang if we delay processing of the incoming data in any way. Fixing this requires first fixing the guest driver to not hold spinlocks while writing to the hvc device backend. Fixes bug: https://bugs.launchpad.net/qemu/+bug/1586756 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1473170165-540-4-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'gdbstub.c')
-rw-r--r--gdbstub.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/gdbstub.c b/gdbstub.c
index 5da66f1..ecea8c4 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -402,7 +402,9 @@ static void put_buffer(GDBState *s, const uint8_t *buf, int len)
}
}
#else
- qemu_chr_fe_write(s->chr, buf, len);
+ /* XXX this blocks entire thread. Rewrite to use
+ * qemu_chr_fe_write and background I/O callbacks */
+ qemu_chr_fe_write_all(s->chr, buf, len);
#endif
}