/* Callback function that's called when the guest sends us data */
static ssize_t flush_buf(VirtIOSerialPort *port,
const uint8_t *buf, ssize_t len)
{
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
ssize_t ret;
if (!vcon->chr) {
/* If there's no backend, we can just say we consumed all data. */
return len;
}
ret = qemu_chr_fe_write(vcon->chr, buf, len);
trace_virtio_console_flush_buf(port->id, len, ret);
if (ret < len) {
VirtIOSerialPortClass *k = VIRTIO_SERIAL_PORT_GET_CLASS(port);
/*
* Ideally we'd get a better error code than just -1, but
* that's what the chardev interface gives us right now. If
* we had a finer-grained message, like -EPIPE, we could close
* this connection.
*/
if (ret < 0)
ret = 0;
if (!k->is_console) {
virtio_serial_throttle_port(port, true);
if (!vcon->watch) {
vcon->watch = qemu_chr_fe_add_watch(vcon->chr, G_IO_OUT,
chr_write_unblocked, vcon);
}
}
}
return ret;
}
/* Callback function that's called when the guest sends us data */
static ssize_t flush_buf(VirtIOSerialPort *port,
const uint8_t *buf, ssize_t len)
{
VirtConsole *vcon = VIRTIO_CONSOLE(port);
ssize_t ret;
if (!qemu_chr_fe_backend_connected(&vcon->chr)) {
/* If there's no backend, we can just say we consumed all data. */
return len;
}
ret = qemu_chr_fe_write(&vcon->chr, buf, len);
trace_virtio_console_flush_buf(port->id, len, ret);
if (ret < len) {
VirtIOSerialPortClass *k = VIRTIO_SERIAL_PORT_GET_CLASS(port);
/*
* Ideally we'd get a better error code than just -1, but
* that's what the chardev interface gives us right now. If
* we had a finer-grained message, like -EPIPE, we could close
* this connection.
*/
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) {
vcon->watch = qemu_chr_fe_add_watch(&vcon->chr,
G_IO_OUT|G_IO_HUP,
chr_write_unblocked, vcon);
}
}
}
return ret;
}
