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). 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. 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?) ... 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". (*) 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? Thanks Laszlo
