From: Gleb Natapov <gleb@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: kvm@vger.kernel.org, Anthony Liguori <aliguori@us.ibm.com>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH][RFC] vmchannel a data channel between host and guest.
Date: Tue, 14 Oct 2008 11:05:40 +0200 [thread overview]
Message-ID: <20081014090540.GB13153@redhat.com> (raw)
In-Reply-To: <48F39443.4070203@codemonkey.ws>
On Mon, Oct 13, 2008 at 01:32:35PM -0500, Anthony Liguori wrote:
> Gleb Natapov wrote:
>> Hello,
>>
>> Sometimes there is a need to pass various bits of information between host
>> and guest (mostly for management purposes such as host screen resolution
>> changes or runtime statistics of a guest). To do that we need some way to
>> pass data between host and guest. Attached patch implements vmchannel that can
>> be used for this purpose. It is based on virtio infrastructure and
>> support more then one channel. The vmchannel presents itself as PCI
>> device to a guest so guest driver is also required. The one for linux is
>> attached. It uses netlink connector to communicate with userspace.
>>
>
> Essentially, the transport itself ends up looking very much like a
> network device so the only real design question is what the guest and
> host interfaces look like. I don't know that a netlink interface is the
> best interface to userspace. Why not a full blown socket? Perhaps a
> virtual file system?
>
netlink was designed to be interface to userspace and is used like this
by different subsystems (not just network). What full blown socket (and
by that I presume you mean new address family) will give you over netlink?
File system? We need a simple stream semantics is this justify another
virtual file system? The choice was between char device and netlink.
Nelink was simpler and gives broadcast as a bonus.
> Having a limit of only 4 links seems like a problem to me too.
>
This can be easily extended.
> I think there needs to be a better articulation about why other
> interfaces cannot be used (like a network device). Is it because of
> ease of guest configuration? Is it performance?
Performance is not the reason. Actually vmchannel doesn't need
performance of a network device that is why its implementation is much
simpler. The main reasons to not use network is that we want to support
configurations where there is no network connectivity between host and
guest. We want to have communication channel available to us even if
guest network stack is misconfigured (actually we may use vmchannel to
configure guest networking). And if we will allocate separate network
device for guest <-> host communication this will be visible to various
guest components that may interfere with it (firewalls, antiviruses).
--
Gleb.
next prev parent reply other threads:[~2008-10-14 9:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-12 12:45 [PATCH][RFC] vmchannel a data channel between host and guest Gleb Natapov
2008-10-13 18:32 ` Anthony Liguori
2008-10-14 9:05 ` Gleb Natapov [this message]
2008-10-14 13:50 ` Anthony Liguori
2008-10-14 17:59 ` Gleb Natapov
2008-10-14 18:16 ` Anthony Liguori
2008-10-15 12:58 ` Gleb Natapov
2008-10-15 12:58 ` Gleb Natapov
2008-10-15 14:02 ` Anthony Liguori
2008-10-16 8:41 ` Gleb Natapov
2008-10-15 14:02 ` Anthony Liguori
2008-10-15 14:18 ` Andrew Biggadike
2008-10-15 14:30 ` Gleb Natapov
2008-10-15 15:00 ` Andrew Biggadike
2008-10-15 14:30 ` Gleb Natapov
2008-10-15 15:42 ` Gleb Natapov
2008-10-15 15:56 ` Anthony Liguori
2008-10-16 8:54 ` Gleb Natapov
2008-10-15 15:56 ` Anthony Liguori
2008-10-15 16:59 ` Andrew Biggadike
2008-10-15 16:59 ` Andrew Biggadike
2008-10-15 14:18 ` Andrew Biggadike
2008-10-14 18:16 ` Anthony Liguori
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=20081014090540.GB13153@redhat.com \
--to=gleb@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=kvm@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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.