Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd.

[Ian Jackson]

Anthony Liguori writes ("Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking 
mode for qemu_chr_open_fd."):
> This changes semantics a bit.  Previously, using a pty would guarantee 
> that data is always written as qemu_chr_write does not perform any sort 
> of buffering.

That depends on what the caller (that is, the internal device model
which is using the char driver) does.

In the case of the serial driver in our tree, the emulated serial port
does not empty its simulated transmit shift register until the data
has been accepted by the char driver - ie, actually delivered to
whereever it is going.

That is, the flow control is communicated back to the guest - perhaps
not in the most optimal way, since perhaps it would be better to
simulate modem flow control lines rather than playing games with
making virtual time run slowly.  But no data will be lost unless the
guest chooses to throw it away - and the guest can get on with the
rest of its life in the meantime.

I'm afraid that this change (which is part of a general improvement to
the flow control handling in hw/serial.c) hasn't made it upstream yet.

But regardless, I think having the whole qemu process block while
writing to a `slow' device like a pty (or a network connection for
that matter) is generally wrong.

I haven't searched for other callers, but if they don't offer a way to
prevent the guest from attempting to write too much then I think that
is a bug in that driver.

Kevin Wolf writes ("Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode 
for        qemu_chr_open_fd."):
> +    if (strstart(filename, "nonblock:", &filename))
> +        block = 0;

This is definitely wrong, because the need for (non)blocking behaviour
is determined statically by the code which is using the driver.

Perhaps there should be two writing interfaces, qemu_chr_write and
qemu_chr_write_(non)block.

qemu_chr_write_block_fd would have to contain a select() or poll()
loop since the fd needs to be in nonblocking mode for the reads to
work correctly without races.

Ian.