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
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 yo
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
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
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 o
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 her
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
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 virtual
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
> -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
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
>> reliabili
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 rou
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
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 rea
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
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