diff options
| author | Daniel P. Berrange <berrange@redhat.com> | 2016-09-06 14:56:04 +0100 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2016-09-13 19:09:42 +0200 |
| commit | 6ab3fc32ea640026726bc5f9f4db622d0954fb8a (patch) | |
| tree | 8a48b6bb8d9746936bfc5cf8119e95f68b8f694a /hw/char/virtio-console.c | |
| parent | 7983e829336f68b6df6952dd4b03493b1486fcf5 (diff) | |
| download | qemu-6ab3fc32ea640026726bc5f9f4db622d0954fb8a.tar.gz | |
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 'hw/char/virtio-console.c')
| -rw-r--r-- | hw/char/virtio-console.c | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/hw/char/virtio-console.c b/hw/char/virtio-console.c index 4f0e03d3b7..d44c18c128 100644 --- a/hw/char/virtio-console.c +++ b/hw/char/virtio-console.c @@ -68,6 +68,27 @@ static ssize_t flush_buf(VirtIOSerialPort *port, */ if (ret < 0) ret = 0; + + /* XXX we should be queuing data to send later for the + * console devices too rather than silently dropping + * console data on EAGAIN. The Linux virtio-console + * hvc driver though does sends with spinlocks held, + * so if we enable throttling that'll stall the entire + * guest kernel, not merely the process writing to the + * console. + * + * While we could queue data for later write without + * enabling throttling, this would result in the guest + * being able to trigger arbitrary memory usage in QEMU + * buffering data for later writes. + * + * So fixing this problem likely requires fixing the + * Linux virtio-console hvc driver to not hold spinlocks + * while writing, and instead merely block the process + * that's writing. QEMU would then need some way to detect + * if the guest had the fixed driver too, before we can + * use throttling on host side. + */ if (!k->is_console) { virtio_serial_throttle_port(port, true); if (!vcon->watch) { |