(In reply to comment #0)
> Read from virtio-serial should block if data is available even if no one is
> connected to the pipe on the host side. Without it application running inside
> the guest is entering a busy-loop while reading nothing.

You should use 'poll' inside the guest app to await data for read (POLLIN) instead of busy-looping.

There's nothing wrong with returning 0 (EOF) when the host-side connection of the pipe is closed.

This isn't really a bug.

I'll close this if there's no objection.

(In reply to comment #2)

> You should use 'poll' inside the guest app to await data for read (POLLIN)
> instead of busy-looping.

I'm not sure 'poll' is supported when working with Python on Windows platform. Will 'poll' will block until the host is connected and wrote something to the pipe?
 
> There's nothing wrong with returning 0 (EOF) when the host-side connection of
> the pipe is closed.

What value will you return if the host-side connection is a socket? You might not be aware to the fact that no one is connected, right?
 
> I'll close this if there's no objection.

You have my objection, but since I open the bug I'm not really objective :-).

(In reply to comment #3)
> (In reply to comment #2)
> 
> > You should use 'poll' inside the guest app to await data for read (POLLIN)
> > instead of busy-looping.
> 
> I'm not sure 'poll' is supported when working with Python on Windows platform.
> Will 'poll' will block until the host is connected and wrote something to the
> pipe?

poll (or even read or write) will block only if host is connected. If host is disconnected, there's no blocking, since you've reached EOF.

If it doesn't work this way, it's either a bug in the virtio-serial Windows guest driver or the way your program works with python.

> > There's nothing wrong with returning 0 (EOF) when the host-side connection of
> > the pipe is closed.
> 
> What value will you return if the host-side connection is a socket? You might
> not be aware to the fact that no one is connected, right?

We're always aware. We (qemu) get to know when a host-side agent is connected or disconnected (well, there's a bug in the disconnect state, but it's a bug, not something we can't know about).

> > I'll close this if there's no objection.
> 
> You have my objection, but since I open the bug I'm not really objective :-).

Well, as far as I can see, things are working just the way they're supposed to.

(In reply to comment #4)

> poll (or even read or write) will block only if host is connected. If host is
> disconnected, there's no blocking, since you've reached EOF.

So we're back to busy-waiting. If I can't block on either read (or poll) I can't tell from guest side when the host is connected to the virtio channel.
 
> If it doesn't work this way, it's either a bug in the virtio-serial Windows
> guest driver or the way your program works with python.

The behavior is the same when running Linux guest.
 
> We're always aware. We (qemu) get to know when a host-side agent is connected
> or disconnected (well, there's a bug in the disconnect state, but it's a bug,
> not something we can't know about).

I'll take a another look in the 'write' behavior.
 
> Well, as far as I can see, things are working just the way they're supposed to.

They are not working as I expect. :-P

(In reply to comment #5)
> (In reply to comment #4)
> 
> > poll (or even read or write) will block only if host is connected. If host is
> > disconnected, there's no blocking, since you've reached EOF.
> 
> So we're back to busy-waiting. If I can't block on either read (or poll) I
> can't tell from guest side when the host is connected to the virtio channel.

OK; I can do a couple of things, as they're done for TCP sockets:
- send a SIGIO when the host-side connection is opened/closed
- allow poll to block even if the host-side connection is closed and return POLLIN when the connection is established.

The second option mentioned above only works for async IO on TCP sockets, but since we don't have a connect()-like call, we can extend poll() to return POLLIN on peer connection.

How about a new verb like accept/connect() ?
Amit, I think we need to provide full documentation for usage of virtio-serial, both from the guest and from the host as well as all the semantics and test cases (that should follow for each of them).

I've added SIGIO support for ports in the guest: you should install a SIGIO handler and set the O_ASYNC flag via fcntl() for the port you are interested in receiving connect/disconnect events.

Once you get a SIGIO signal, you can poll() all your ports in the signal handler to find out which port got opened or closed.

You will also receive a SIGIO when input becomes available, so you need not poll() for POLLIN.

poll() will still return POLLHUP for unconnected hosts since that's the only way of knowing whether a host-side connection is up or down.

The patch will be posted upstream in a bit and will be proposed for 6.1.

To see how to enable this functionality in a guest app, see

http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git;a=commitdiff;h=fa6dce3c8cfe718a0ed54e08d6ae384c5185ca6c

For more tests relating to the new SIGIO signal, see

http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git;a=commitdiff;h=af6f49a6cf54cdf76531eba26e605a9a1503d185

http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git;a=commitdiff;h=5c468270518dac6fd083f7527ae3a9992d154f0f

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Was it tested also on windows guest?

Patch(es) available on kernel-2.6.32-89.el6

(In reply to comment #22)
> Hi Amit,
> 
> Can you please provide the steps to verify?

See comment 8 for what was done and how to verify.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, a guest could use the poll() function to find out whether the host-side connection was open or closed. However, with a SIGIO signal, this can be done asynchronously, without having to explicitly poll each port. With this update, a SIGIO signal is sent for any host connect/disconnect events. Once the SIGIO signal is received, the open/close status of virtio-serial ports can be obtained using the poll() system call.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0542.html