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