qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for bufferin


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for buffering guest output, throttling guests
Date: Wed, 23 Dec 2009 17:17:48 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0

On 12/23/2009 01:52 PM, Amit Shah wrote:
Guests send us one buffer at a time. Current guests send buffers sized
4K bytes. If guest userspace applications sent out>  4K bytes in one
write() syscall, the write request actually sends out multiple buffers,
each of 4K in size.

This usually isn't a problem but for some apps, like VNC, the entire
data has to be sent in one go to make copy/paste work fine. So if an app
on the guest sends out guest clipboard contents, it has to be sent to
the vnc server in one go as the guest app sent it.

For this to be done, we need the guest to send us START and END markers
for each write request so that we can find out complete buffers and send
them off to ports.

This needs us to buffer all the data that comes in from the guests, hold
it off till we see all the data corresponding to one write request,
merge it all in one buffer and then send it to the port the data was
destined for.

Also, we add support for caching of these buffers till a port indicates
it's ready to receive data.

We keep caching data the guest sends us till a port accepts it. However,
this could lead to an OOM condition where a rogue process on the guest
could continue pumping in data while the host continues to cache it.

We introduce a per-port byte-limit property to alleviate this condition.
When this limit is reached, we send a control message to the guest
indicating it to not send us any more data till further indication. When
the number of bytes cached go lesser than the limit specified, we open
tell the guest to restart sending data.

Signed-off-by: Amit Shah<address@hidden>
---
  hw/virtio-serial-bus.c |  315 +++++++++++++++++++++++++++++++++++++++++++++++-
  hw/virtio-serial.c     |    7 +
  hw/virtio-serial.h     |   44 +++++++
  3 files changed, 364 insertions(+), 2 deletions(-)


+static void flush_all_ports(VirtIOSerial *vser)
+{
+    struct VirtIOSerialPort *port;
+
+    QTAILQ_FOREACH(port,&vser->ports, next) {
+        pthread_mutex_lock(&port->unflushed_buffers_lock);
+        if (port->has_activity) {
+            port->has_activity = false;
+            flush_queue(port);
+        }
+        pthread_mutex_unlock(&port->unflushed_buffers_lock);
+    }
+}
+
+static void remove_port_buffers(VirtIOSerialPort *port)
+{
+    struct VirtIOSerialPortBuffer *buf, *buf2;
+
+    pthread_mutex_lock(&port->unflushed_buffers_lock);
+    QTAILQ_FOREACH_SAFE(buf,&port->unflushed_buffers, next, buf2) {
+        QTAILQ_REMOVE(&port->unflushed_buffers, buf, next);
+        free_buf(buf);
+    }
+    pthread_mutex_unlock(&port->unflushed_buffers_lock);
+}

The locking here is unnecessary.

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]