From: Anthony Liguori <anthony@codemonkey.ws>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: kvm@vger.kernel.org, "Richard W.M. Jones" <rjones@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
Amit Shah <amit.shah@redhat.com>
Subject: Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Date: Mon, 10 Aug 2009 09:20:23 -0500 [thread overview]
Message-ID: <4A802CA7.9020701@codemonkey.ws> (raw)
In-Reply-To: <4A80287C.7050400@redhat.com>
Gerd Hoffmann wrote:
> On 08/10/09 15:02, Anthony Liguori wrote:
>
>> I think you're missing my fundamental point. Don't use the kernel as the
>> guest interface.
>>
>> Introduce a userspace daemon that exposes a domain socket. Then we can
>> have a proper protocol that uses reverse fqdns for identification.
>
> We need nothing but (a) bidirectional byte streams and (b) name tags
> for them.
>
> Do we really want design a daemon and a protocol for such a simple thing?
Yes, because we also need (c) the ability to write cross platform
software that targets vmchannel.
So having a library interface is going to be extremely desirable.
Also, see the previous discussion about security. How do you sanely
delegate /dev/vmchannel/org/qemu/clipboard to the current Xorg user?
> Especially as requiring a daemon for that adds a few problems you
> don't have without them. Access control for example: For device
> nodes you can just use standard unix permissions and acls.
But how do you set those permissions in the first place?
> You can easily do stuff like adding the logged in desktop user to
> the /dev/vmchannel/org/qemu/clipboard acl using existing solutions.
> With a daemon you have to hop through a number of loops to archive the
> same.
>
> Can't we simply have guest apps open "/dev/vmchannel/$protocol" ?
/dev interfaces are only simple to kernel developers :-) Besides, why
do something that can be clearly done in userspace within the kernel?
It just increases the possibility of kernel bugs.
You can have a /var/run/vmchannel/$protocol.sock unix domain socket and
it has all the same properties that you describe. It also Just Works
with standard tools like socat. You can transparently route it over the
network, have it work over slirp, a serial device, or some custom virtio
device if we so choose.
It's the only sane way to support older guests too. If we really want
vmchannel to be used by application developers, then we really need a
libvmchannel.
Regards,
Anthony Liguori
> cheers,
> Gerd
>
next prev parent reply other threads:[~2009-08-10 14:20 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-27 18:04 [Qemu-devel] virtio-serial: An interface for host-guest communication Amit Shah
2009-07-27 18:04 ` [Qemu-devel] [PATCH 1/1] virtio_serial: A char device for simple guest <-> host communication Amit Shah
2009-07-27 18:04 ` [Qemu-devel] [PATCH 1/3] virtio-serial: virtio device for simple host <-> guest communication Amit Shah
2009-07-27 18:04 ` [Qemu-devel] [PATCH 2/3] vnc: add a is_vnc_active() helper Amit Shah
2009-07-27 18:04 ` [Qemu-devel] [PATCH 3/3] virtio-serial: vnc: support for sending / receiving guest clipboard Amit Shah
2009-08-05 0:03 ` [Qemu-devel] Re: [PATCH 1/1] virtio_serial: A char device for simple guest <-> host communication Rusty Russell
2009-08-05 5:12 ` Amit Shah
2009-08-05 9:58 ` Amit Shah
2009-07-27 20:22 ` [Qemu-devel] Re: virtio-serial: An interface for host-guest communication Anthony Liguori
2009-07-27 20:32 ` Daniel P. Berrange
2009-07-27 20:37 ` Anthony Liguori
2009-07-27 20:46 ` Jamie Lokier
2009-07-27 23:44 ` Anthony Liguori
2009-07-28 10:36 ` Amit Shah
[not found] ` <4A6F0048.1000103@codemonkey.ws>
2009-07-29 7:44 ` Amit Shah
2009-07-29 7:48 ` Gleb Natapov
2009-08-05 18:00 ` Jamie Lokier
[not found] ` <20090728140029.GA16067@amd.home.annexia.org>
2009-07-28 14:48 ` Anthony Liguori
2009-07-28 14:55 ` Richard W.M. Jones
2009-07-28 15:00 ` Anthony Liguori
2009-08-03 19:57 ` Anthony Liguori
2009-08-05 17:57 ` Jamie Lokier
2009-08-05 18:00 ` Anthony Liguori
2009-08-06 10:38 ` Amit Shah
2009-08-06 13:29 ` Anthony Liguori
2009-08-06 13:41 ` Amit Shah
2009-08-06 13:58 ` Anthony Liguori
2009-08-06 14:04 ` Amit Shah
2009-08-06 17:37 ` Jamie Lokier
2009-08-07 6:38 ` Amit Shah
2009-08-07 14:14 ` Anthony Liguori
2009-08-10 6:55 ` Amit Shah
2009-08-10 9:47 ` Gerd Hoffmann
2009-08-10 13:02 ` Anthony Liguori
2009-08-10 14:02 ` Gerd Hoffmann
2009-08-10 14:20 ` Anthony Liguori [this message]
2009-08-10 15:34 ` Gerd Hoffmann
2009-08-10 16:59 ` Anthony Liguori
2009-08-10 17:27 ` Anthony Liguori
2009-08-12 18:27 ` Paul Brook
2009-08-14 8:15 ` Amit Shah
2009-08-14 13:29 ` Anthony Liguori
2009-08-14 13:41 ` Amit Shah
2009-08-20 13:42 ` Amit Shah
2009-08-20 14:25 ` Daniel P. Berrange
2009-08-20 14:38 ` Amit Shah
2009-08-20 14:42 ` Amit Shah
2009-08-14 13:49 ` Gerd Hoffmann
2009-08-14 16:25 ` Anthony Liguori
2009-08-20 7:31 ` Rusty Russell
2009-08-20 7:44 ` Gerd Hoffmann
2009-08-20 7:55 ` Amit Shah
2009-08-20 17:10 ` Jamie Lokier
2009-08-25 12:43 ` Rusty Russell
2009-08-25 13:00 ` Gerd Hoffmann
2009-08-10 14:20 ` Anthony Liguori
2009-08-10 23:09 ` Rusty Russell
2009-08-11 0:16 ` Anthony Liguori
2009-08-10 14:27 ` Anthony Liguori
2009-08-10 15:57 ` Gerd Hoffmann
2009-08-06 10:35 ` Amit Shah
2009-08-05 18:32 ` Richard W.M. Jones
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=4A802CA7.9020701@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=amit.shah@redhat.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.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).