|
From: | Michael Roth |
Subject: | [Qemu-devel] Re: virtio-serial semantics for binary data and guest agents |
Date: | Wed, 23 Feb 2011 08:31:52 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |