From: Laszlo Ersek <lersek@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Amit Shah <amit.shah@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [Qemu-devel] qemu-ga behavior on virtio-serial unplug
Date: Wed, 19 Jun 2013 13:17:57 +0200 [thread overview]
Message-ID: <51C19365.5050606@redhat.com> (raw)
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
next reply other threads:[~2013-06-19 11:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 11:17 Laszlo Ersek [this message]
2013-06-20 13:31 ` [Qemu-devel] qemu-ga behavior on virtio-serial unplug Amit Shah
2013-06-20 18:56 ` Laszlo Ersek
2013-06-20 15:12 ` mdroth
2013-06-20 15:20 ` mdroth
2013-08-13 12:00 ` Amit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C19365.5050606@redhat.com \
--to=lersek@redhat.com \
--cc=amit.shah@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).