From: "Richard W.M. Jones" <rjones@redhat.com>
To: Chris Friesen <chris.friesen@windriver.com>
Cc: Amit Shah <amit.shah@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] questions about host side of virtio-serial
Date: Thu, 31 Jul 2014 10:32:24 +0100 [thread overview]
Message-ID: <20140731093224.GB14001@redhat.com> (raw)
In-Reply-To: <53D93EF9.3020505@windriver.com>
On Wed, Jul 30, 2014 at 12:52:41PM -0600, Chris Friesen wrote:
> Hi,
>
> I'm working on a native user of virtio-serial (ie, not going via the
> qemu guest agent).
>
> The information at "http://www.linux-kvm.org/page/Virtio-serial_API"
> does a good job of describing the guest side of things, but has very
> little information about the host side of things.
You might also want to read the libguestfs source code, since
libguestfs is a major and long-time user of virtio-serial.
In particular these files:
src/launch-direct.c
src/proto.c
src/conn-socket.c
daemon/proto.c
src/launch-libvirt.c # if interested in using virtio-serial from libvirt
> In particular, assuming that the host side is using a chardev mapped
> to a unix socket:
>
> 1) Is there any way for the host app to get information about
> whether or not the guest is reading the messages? (i.e. logically
> equivalent to getting POLLHUP in the guest when the host app
> disconnects.)
No, I don't believe that is possible. It acts like a real serial port
and throws away bytes when no one is listening (on both ends).
> 2) Suppose the host sends a large message. The guest app reads a
> portion of the message, then crashes. We respawn the guest app and
> start reading again, but now we're in the middle of a message of
> arbitrary size. Is there a recommended technique to re-sync the
> host and guest?
AFAIK that's either very difficult or impossible. Maybe with some
kind of self-synchronizing protocol, or if you ran SLIP/PPP on top of
the raw virtio-serial channel?
In the libguestfs case we wouldn't even try to go there -- if
something in the VM crashes we completely recreate the virtual machine
from scratch.
> 3) Same as 2, but the guest sending to the host and the host app
> crashing partway through.
>
> 4) If nothing in the guest is reading the data, how much data can
> the host send before it will get an error?
It won't get an error - the sender will block. Except on ARM where
there is a race condition in virtio-mmio causing writes to be thrown
away (https://bugs.launchpad.net/qemu/+bug/1224444).
> Is there a way to adjust this?
Not as far as I know.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
next prev parent reply other threads:[~2014-07-31 9:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 18:52 [Qemu-devel] questions about host side of virtio-serial Chris Friesen
2014-07-31 9:32 ` Richard W.M. Jones [this message]
2014-07-31 14:45 ` Chris Friesen
2014-07-31 15:07 ` Paolo Bonzini
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=20140731093224.GB14001@redhat.com \
--to=rjones@redhat.com \
--cc=amit.shah@redhat.com \
--cc=chris.friesen@windriver.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.