Hi Gleb.
On Wed, Dec 17, 2008 at 04:31:46PM +0200, Gleb Natapov (g...@redhat.com) wrote:
> Here it is. Sorry it is not in a patch format yet, but it gives
> general idea how it looks. The problem with connector is that
> we need different IDX for different channels and there is no way
> to dynami
On Wed, Dec 17, 2008 at 12:25:32AM +0300, Evgeniy Polyakov wrote:
> On Tue, Dec 16, 2008 at 08:57:27AM +0200, Gleb Natapov (g...@redhat.com)
> wrote:
> > > Another approach is to implement that virtio backend with netlink based
> > > userspace interface (like using connector or genetlink). This do
Evgeniy Polyakov wrote:
On Tue, Dec 16, 2008 at 08:57:27AM +0200, Gleb Natapov (g...@redhat.com) wrote:
Another approach is to implement that virtio backend with netlink based
userspace interface (like using connector or genetlink). This does not
differ too much from what you have with specia
On Tue, Dec 16, 2008 at 08:57:27AM +0200, Gleb Natapov (g...@redhat.com) wrote:
> > Another approach is to implement that virtio backend with netlink based
> > userspace interface (like using connector or genetlink). This does not
> > differ too much from what you have with special socket family, b
On Tue, Dec 16, 2008 at 02:45:11AM +0300, Evgeniy Polyakov wrote:
> Hi Anthony.
>
> On Mon, Dec 15, 2008 at 05:01:14PM -0600, Anthony Liguori
> (anth...@codemonkey.ws) wrote:
> > Yes, and I went down the road of using a dedicated network device and
> > using raw ethernet as the protocol. The th
Anthony Liguori wrote:
>
> If we used TCP, we don't have a useful TCP/IP stack in QEMU, so we'd
> have to inject that traffic into the host Linux instance, and then
> receive the traffic in QEMU. Besides being indirect, it has some nasty
> security implications that I outlined in my response
Evgeniy Polyakov wrote:
On Mon, Dec 15, 2008 at 05:08:29PM -0600, Anthony Liguori
(anth...@codemonkey.ws) wrote:
The KVM model is that a guest is a process. Any IO operations original
from the process (QEMU). The advantage to this is that you get very
good security because you can use thi
On Mon, Dec 15, 2008 at 05:08:29PM -0600, Anthony Liguori
(anth...@codemonkey.ws) wrote:
> The KVM model is that a guest is a process. Any IO operations original
> from the process (QEMU). The advantage to this is that you get very
> good security because you can use things like SELinux and si
Hi Anthony.
On Mon, Dec 15, 2008 at 05:01:14PM -0600, Anthony Liguori
(anth...@codemonkey.ws) wrote:
> Yes, and I went down the road of using a dedicated network device and
> using raw ethernet as the protocol. The thing that killed that was the
> fact that it's not reliable. You need somethi
Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
That seems unnecessarily complex.
Well, the simplest thing is to let the host TCP stack do TCP. Could
you go into more detail about why you'd want to avoid that?
The KVM model is that a guest is a process. Any I
David Miller wrote:
From: Anthony Liguori
Date: Mon, 15 Dec 2008 17:01:14 -0600
No, TCP falls under the not simple category because it requires the
backend to have access to a TCP/IP stack.
I'm at a loss for words if you need TCP in the hypervisor, if that's
what you're implying here
On Mon, 15 Dec 2008 17:01:14 -0600
Anthony Liguori wrote:
> David Miller wrote:
> > From: Anthony Liguori
> > Date: Mon, 15 Dec 2008 14:44:26 -0600
> >
> >
> >> We want this communication mechanism to be simple and reliable as we
> >> want to implement the backends drivers in the host userspa
From: Anthony Liguori
Date: Mon, 15 Dec 2008 17:01:14 -0600
> No, TCP falls under the not simple category because it requires the
> backend to have access to a TCP/IP stack.
I'm at a loss for words if you need TCP in the hypervisor, if that's
what you're implying here.
You only need it in the g
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
That seems unnecessarily complex.
Well, the simplest thing is to let the host TCP stack do TCP. Could
you go into more detail about why you'd want to avoid that?
The KVM model is that a guest is a process. Any IO operations original
f
David Miller wrote:
From: Anthony Liguori
Date: Mon, 15 Dec 2008 14:44:26 -0600
We want this communication mechanism to be simple and reliable as we
want to implement the backends drivers in the host userspace with
minimum mess.
One implication of your statement here is that TCP is u
Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Each of these sockets are going to be connected to a backend (to
implement guest<=>copy/paste for instance). We want to implement
those backends in userspace and preferably in QEMU.
Using some raw protocol over ethernet means you don't hav
From: Anthony Liguori
Date: Mon, 15 Dec 2008 14:44:26 -0600
> We want this communication mechanism to be simple and reliable as we
> want to implement the backends drivers in the host userspace with
> minimum mess.
One implication of your statement here is that TCP is unreliable.
That's absolute
David Miller wrote:
From: Anthony Liguori
Date: Mon, 15 Dec 2008 09:02:23 -0600
There is already an AF_IUCV for s390.
This is a scarecrow and irrelevant to this discussion.
And this is exactly why I asked that any arguments in this thread
avoid talking about virtualization technolog
From: Anthony Liguori
Date: Mon, 15 Dec 2008 09:02:23 -0600
> There is already an AF_IUCV for s390.
This is a scarecrow and irrelevant to this discussion.
And this is exactly why I asked that any arguments in this thread
avoid talking about virtualization technology and why it's "special."
Thi
Jeremy Fitzhardinge wrote:
Each of these sockets are going to be connected to a backend (to
implement guest<=>copy/paste for instance). We want to implement
those backends in userspace and preferably in QEMU.
Using some raw protocol over ethernet means you don't have
reliability. If you use
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Jeremy Fitzhardinge
> The trouble is that it presumes that the host and guest (or whoever the
> endpoints are) are on the same physical machine and will remain that
> way. Given that
Anthony Liguori wrote:
David Miller wrote:
From: Gleb Natapov
Date: Sun, 14 Dec 2008 13:50:55 +0200
It is undesirable to use TCP/IP for this purpose since network
connectivity may not exist between host and guest and if it exists the
traffic can be not routable between host and gue
David Miller wrote:
From: Gleb Natapov
Date: Sun, 14 Dec 2008 13:50:55 +0200
It is undesirable to use TCP/IP for this purpose since network
connectivity may not exist between host and guest and if it exists the
traffic can be not routable between host and guest for security reasons
or TCP/I
From: Gleb Natapov
Date: Mon, 15 Dec 2008 09:48:19 +0200
> On Sun, Dec 14, 2008 at 10:44:36PM -0800, David Miller wrote:
> > You guys really need to rethink this. Either a stream protocol is a
> > workable solution to your problem, or it isn't.
>
> Stream protocol is workable solution for us, bu
On Sun, Dec 14, 2008 at 10:44:36PM -0800, David Miller wrote:
> From: Gleb Natapov
> Date: Sun, 14 Dec 2008 13:50:55 +0200
>
> > It is undesirable to use TCP/IP for this purpose since network
> > connectivity may not exist between host and guest and if it exists the
> > traffic can be not routabl
From: Gleb Natapov
Date: Sun, 14 Dec 2008 13:50:55 +0200
> It is undesirable to use TCP/IP for this purpose since network
> connectivity may not exist between host and guest and if it exists the
> traffic can be not routable between host and guest for security reasons
> or TCP/IP traffic can be f
Hi Evgeniy,
On Sun, Dec 14, 2008 at 03:23:20PM +0300, Evgeniy Polyakov wrote:
> On Sun, Dec 14, 2008 at 01:50:55PM +0200, Gleb Natapov (g...@redhat.com)
> wrote:
> > There is a need for communication channel between host and various
> > agents that are running inside a VM guest. The channel will
Hi Gleb.
On Sun, Dec 14, 2008 at 01:50:55PM +0200, Gleb Natapov (g...@redhat.com) wrote:
> There is a need for communication channel between host and various
> agents that are running inside a VM guest. The channel will be used
> for statistic gathering, logging, cut & paste, host screen resolutio
There is a need for communication channel between host and various
agents that are running inside a VM guest. The channel will be used
for statistic gathering, logging, cut & paste, host screen resolution
changes notifications, guest configuration etc.
It is undesirable to use TCP/IP for this purp
29 matches
Mail list logo
