> > > > > 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
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 ch
> > > 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 c
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 t
> > 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.
>
>
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 incorrect
> 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 n
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 t
> > > 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_c
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_throt
> 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);
> > > > > +}
> > > > >
> > > > >
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;
> >
> /* 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 = qemu_
> > > -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
>
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);
> > > > +}
> > > >
> > > > }
> > >
> > > T
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 indi
16 matches
Mail list logo
