From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upey1-0002c5-O1 for qemu-devel@nongnu.org; Thu, 20 Jun 2013 09:32:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Upey0-0007hS-9j for qemu-devel@nongnu.org; Thu, 20 Jun 2013 09:32:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upey0-0007gz-2p for qemu-devel@nongnu.org; Thu, 20 Jun 2013 09:32:00 -0400 Date: Thu, 20 Jun 2013 19:01:05 +0530 From: Amit Shah Message-ID: <20130620133003.GA3347@amit-x200.redhat.com> References: <51C19365.5050606@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C19365.5050606@redhat.com> Subject: Re: [Qemu-devel] qemu-ga behavior on virtio-serial unplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Michael Roth , "qemu-devel@nongnu.org" On (Wed) 19 Jun 2013 [13:17:57], Laszlo Ersek wrote: > 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). 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