Re: [Qemu-devel] qemu-ga behavior on virtio-serial unplug

[Amit Shah]

On (Wed) 19 Jun 2013 [13:17:57], Laszlo Ersek wrote:
> Hello Michael,
> 
> this is with reference to
> <https://bugzilla.redhat.com/show_bug.cgi?id=907733>.
> 
> Ever since the initial qemu-ga commit AFAICS an exception for
> virtio-serial has existed, when reading EOF from the channel.
> 
> For isa-serial, EOF results in the client connection being closed. I
> assume this exits the glib main loop somehow (otherwise qemu-ga would
> just sit there and do nothing, as no further connections are accepted I
> think).
> 
> For a unix domain socket, we can continue accepting new connections
> after reading EOF.
> 
> For virtio-serial, EOF means "no host-side process is connected". In
> this case we sleep a bit and go back to reading from the same fd (and
> this turns into a sleep loop until the next host-side process connects).

There's also another bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=975661
virtio_console: read() returns 0 after port unplug

write() calls return an error if a port has been unplugged, but read()
calls don't (in all cases -- see the link above for details).  I'm
going to fix this in kernel 3.11 (and possibly mark it for stable@).

> Can we tell "virtio-serial port unplug" from "no host-side process"?
> Because in the former case qemu-ga should really close the channel (and
> maybe exit (*)), otherwise the unplug won't complete in the guest kernel.

Yes, after the above fix, this will be the case.  read()s will return
error.

Also, poll(2) should return POLLHUP|POLLERR instead of just POLLHUP in
this case -- I'll fix that as well.

> According to Amit's comments in the RHBZ, at unplug a SIGIO is
> delivered, and a POLLHUP event is reported. However,
> 
> (a) I think the glib iochannel abstraction doesn't allow us to tell
> POLLHUP apart from reading EOF;
> 
> (b) delivery of an unhandled SIGIO seems to terminate the victim
> process. qemu-ga doesn't seem to either catch or block SIGIO, which is
> why I think a SIGIO signal is not sent in reality (maybe we should ask
> for it first?)

Bah, I saw another bug in the kernel, and you're right: the signal
isn't actually sent on unplug (it's only sent on host connecting and
disconnecting).  Fix on the way as well.

> ... Actually I'm confused about this as well. The virtio-serial port
> *is* opened with O_ASYNC (and on Solaris, it is replaced with an
> I_SETSIG ioctl()). What's the reason for this? g_io_channel_unix_new()
> doesn't seem to list it as a requirement, and qemu-ga doesn't seem to
> handle SIGIO.
> 
> In any case we'd need a way to tell "host side close" from "port unplug".

Will POLLHUP|POLLERR help, along with error returns on read() and
write()?

> (*) Then, there's the question what to do after unplug. Should we keep
> reopening the same virtio-serial port (and sleeping a bit in-between)?
> Or exit and let udev / systemd restart qemu-ga on any new virtio-serial
> port, passing -p accordingly?

I like the idea to defer to udev or systemd activation.

                Amit