[Qemu-devel] Re: virtio-serial semantics for binary data and guest agents

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 02/22/2011 10:59 PM, Amit Shah wrote:
> On (Tue) 22 Feb 2011 [16:40:55], Michael Roth wrote:
>> If something in the guest is attempting to read/write from the
>> virtio-serial device, and nothing is connected to virtio-serial's
>> host character device (say, a socket)
>>
>> 1. writes will block until something connect()s, at which point the
>> write will succeed
>>
>> 2. reads will always return 0 until something connect()s, at which
>> point the reads will block until there's data
>>
>> This makes it difficult (impossible?) to implement the notion of
>> connect/disconnect or open/close over virtio-serial without layering
>> another protocol on top using hackish things like length-encoded
>> payloads or sentinel values to determine the end of one
>> RPC/request/response/session and the start of the next.
>>
>> For instance, if the host side disconnects, then reconnects before
>> we read(), we may never get the read()=0, and our FD remains valid.
>> Whereas with a tcp/unix socket our FD is no longer valid, and the
>> read()=0 is an event we can check for at any point after the other
>> end does a close/disconnect.
>
> There's SIGIO support, so host connect-disconnect notifications can be
> caught via the signal.

I recall looking into this at some point....but don't we get a SIGIO for 
read/write-ability in general? So you still need some way differentiate, 
say, readability from a disconnect/EOF, and the read()=0 that could 
determine this is still racing with host-side reconnects.

>
> Also, nonblocking reads/writes will return -EPIPE if the host-side
> connection is not up.

But we still essentially need to poll() for a host-side disconnected 
state, which is still racy since they may reconnect before we've done a 
read/write that would've generated the -EPIPE. It seems like what we 
really need is for the FD to be invalid from that point forward.

Also, I focused more on the guest-side connect/disconnect detection, but 
as Anthony mentioned I think the host side shares similar limitations as 
well. AFAIK once we connect to the chardev that FD remains valid until 
the connected process closes it, and so races with the guest side on 
detecting connect/disconnect events in a similar manner. For the host 
side it looks like virtio-console has guest_close/guest_open callbacks 
already that we could potentially use...seems like it's just a matter of 
tying them to the chardev... basically having virtio-serial's 
guest_close() result in a close() on the corresponding chardev 
connection's FD.

>
> 		Amit