From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpGMU-0004eS-N3 for qemu-devel@nongnu.org; Wed, 19 Jun 2013 07:15:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpGMR-00012o-Do for qemu-devel@nongnu.org; Wed, 19 Jun 2013 07:15:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpGMR-00012a-55 for qemu-devel@nongnu.org; Wed, 19 Jun 2013 07:15:35 -0400 Message-ID: <51C19365.5050606@redhat.com> Date: Wed, 19 Jun 2013 13:17:57 +0200 From: Laszlo Ersek MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] qemu-ga behavior on virtio-serial unplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Amit Shah , "qemu-devel@nongnu.org" Hello Michael, this is with reference to . 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