All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.