But that's entirely in guest memory, so it's limited to the amount
of RAM that has been allocated to the guest.
Exactly. The guest can cause ram_size * nr_ports of additional host
memory to be allocated. Not acceptable.
OK -- so this is how it adds up:
- guest
Sure. My proposal is for qemu_chr_write() to succeed all the time. If
the backend can block, and the caller can handle it, it can get a
-EAGAIN (or WSAEWOULDBLOCK) return. When the backend becomes writable,
the chardev can call the -writes_unblocked() callback for that caller.
On (Wed) Dec 08 2010 [12:56:33], Paul Brook wrote:
Sure. My proposal is for qemu_chr_write() to succeed all the time. If
the backend can block, and the caller can handle it, it can get a
-EAGAIN (or WSAEWOULDBLOCK) return. When the backend becomes writable,
the chardev can call
On (Thu) Dec 02 2010 [17:31:36], Paul Brook wrote:
when there's a partial write, it tries to do a write again, which
will fail with -EAGAIN.
Doesn't that cause the first partial chunk to be incorrectly
transmitted twice? You may only return EAGAIN if no data was
On (Mon) Dec 06 2010 [09:35:10], Paul Brook wrote:
On (Thu) Dec 02 2010 [17:31:36], Paul Brook wrote:
when there's a partial write, it tries to do a write again, which
will fail with -EAGAIN.
Doesn't that cause the first partial chunk to be incorrectly
transmitted
As with the DMA interface added a while ago, I believe it's important to
get these APIs right. Quick hacks to support limited use-cases just end
up needing a complete rewrite (or even worse multiple concurrent
APIs/implementations) once we actually start using them seriously.
Sure. My
On (Mon) Dec 06 2010 [13:23:50], Paul Brook wrote:
Sure. My proposal is for qemu_chr_write() to succeed all the time. If
the backend can block, and the caller can handle it, it can get a
-EAGAIN (or WSAEWOULDBLOCK) return. When the backend becomes writable,
the chardev can call the
On (Thu) Dec 02 2010 [17:31:36], Paul Brook wrote:
when there's a partial write, it tries to do a write again, which will
fail with -EAGAIN.
Doesn't that cause the first partial chunk to be incorrectly transmitted
twice? You may only return EAGAIN if no data was transmitted.
On (Wed) Dec 01 2010 [13:08:26], Paul Brook wrote:
On (Wed) Dec 01 2010 [11:59:35], Paul Brook wrote:
-qemu_chr_write(vcon-chr, buf, len);
+ret = qemu_chr_write(vcon-chr, buf, len);
+if (ret == -EAGAIN) {
+virtio_serial_throttle_port(port, true);
when there's a partial write, it tries to do a write again, which will
fail with -EAGAIN.
Doesn't that cause the first partial chunk to be incorrectly transmitted
twice? You may only return EAGAIN if no data was transmitted.
Except for the fact that no caller of qemu_chr_write()
When a chardev indicates it can't accept more data, we tell the
virtio-serial code to stop sending us any more data till we tell
otherwise. This helps in guests continuing to run normally while the vq
keeps getting full and eventually the guest stops queueing more data.
As soon as the chardev
On (Wed) Dec 01 2010 [11:59:35], Paul Brook wrote:
-qemu_chr_write(vcon-chr, buf, len);
+ret = qemu_chr_write(vcon-chr, buf, len);
+if (ret == -EAGAIN) {
+virtio_serial_throttle_port(port, true);
+}
}
This looks wrong. It will loose data
-qemu_chr_write(vcon-chr, buf, len);
+ret = qemu_chr_write(vcon-chr, buf, len);
+if (ret == -EAGAIN) {
+virtio_serial_throttle_port(port, true);
+}
}
This looks wrong. It will loose data in the case of a partial write
(i.e. ret len)
That
/* Callback function that's called when the guest sends us data */
static void flush_buf(VirtIOSerialPort *port, const uint8_t *buf, size_t
len) {
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
+int ret;
-qemu_chr_write(vcon-chr, buf, len);
+ret =
On (Wed) Dec 01 2010 [11:30:58], Paul Brook wrote:
/* Callback function that's called when the guest sends us data */
static void flush_buf(VirtIOSerialPort *port, const uint8_t *buf, size_t
len) {
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
+int ret;
-
On (Wed) Dec 01 2010 [11:59:35], Paul Brook wrote:
-qemu_chr_write(vcon-chr, buf, len);
+ret = qemu_chr_write(vcon-chr, buf, len);
+if (ret == -EAGAIN) {
+virtio_serial_throttle_port(port, true);
+}
}
This looks wrong. It will
16 matches
Mail list logo
