From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LM1uc-0004cv-9S for qemu-devel@nongnu.org; Sun, 11 Jan 2009 10:07:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LM1ub-0004bp-D8 for qemu-devel@nongnu.org; Sun, 11 Jan 2009 10:07:38 -0500 Received: from [199.232.76.173] (port=51515 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LM1ub-0004bh-5w for qemu-devel@nongnu.org; Sun, 11 Jan 2009 10:07:37 -0500 Received: from mx2.redhat.com ([66.187.237.31]:33105) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LM1ua-00043L-Hp for qemu-devel@nongnu.org; Sun, 11 Jan 2009 10:07:36 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0BF7ZEQ015353 for ; Sun, 11 Jan 2009 10:07:35 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n0BF7Zs4026394 for ; Sun, 11 Jan 2009 10:07:35 -0500 Received: from localhost.localdomain (dhcp-1-189.tlv.redhat.com [10.35.1.189]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n0BF7X5s027848 for ; Sun, 11 Jan 2009 10:07:34 -0500 Message-ID: <496A0B4C.7000004@redhat.com> Date: Sun, 11 Jan 2009 17:07:56 +0200 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] mark nic as trusted References: <496501CD.8060202@codemonkey.ws> <49665AE7.3000708@codemonkey.ws> <20090108212652.GB22504@redhat.com> <49667330.5070001@codemonkey.ws> <20090108224942.GA12848@shareable.org> <496688D9.1040708@redhat.com> <20090109104154.GA5164@redhat.com> <20090110021811.GJ1972@shareable.org> <4968E74E.5040905@codemonkey.ws> <20090111045524.GB15975@shareable.org> <4969FD59.10509@gmx.net> In-Reply-To: <4969FD59.10509@gmx.net> Content-Type: multipart/alternative; boundary="------------020802080208030108030604" Reply-To: dlaor@redhat.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------020802080208030108030604 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Carl-Daniel Hailfinger wrote: > On 11.01.2009 08:10, Blue Swirl wrote: > >> On 1/11/09, Jamie Lokier wrote: >> >> >>> > But we also have to think about how to support newer platforms and newer >>> > kernels and this will often mean that we have to make intrusive changes >>> > so that the integration makes everyone happy. This does not mean that >>> > we cannot support older platforms though, we just have to do it a little >>> > differently on the older platforms. >>> >>> Sure, but don't make it _deliberately_ hard to support >>> older/obscure/can't-compile-a-kernel-module guests by designing >>> something that's obviously going to require a totally different >>> mechanism on those other guests. It would make it unnecessarily hard >>> to integrate diverse guests with management apps from different >>> authors if they do adopt the vmchannel mechanism. >>> >>> >> I think a serial port device should be universally supported by any OS >> and it's portable to many systems. Older OS may accidentally enable >> forwarding between the trusted nic and other nics, this doesn't happen >> with serial lines. >> >> > > I remember the old days of DOS networking where the Kirschbaum-Netz > software provided some sort of routed/forwarded networking between PCs > over serial ports. It was a default on choice in many corporate and > private "LANs" in Germany at the beginning of the last decade. > > Except for machines with that software (which is really hard to get > nowadays), my concern should be a non-issue, especially for virtual > machines which are unlikely to have such software installed. > > Regards, > Carl-Daniel > > Actually vmchannel started as a pv serial implementation. Standard serial is a bit low performing and demand an vmexit per byte (maybe it's not that bad for us). Moreover, various guest do not support more than 4 serial channels. Since there should be several channels and we like to preserve some for console/debug, it is not enough. Originally, vmchannel was a virtio interface with netlink interface to the kernel. Then, Anthony asked to change it to a socket interface with new address family. It was indeed a logical step. Then, David Miller was reluctant to add such interface to the kernel. Instead, he offered the network device solution. Are we close to begin this loop again? :) Let's try to stick to the nic solution. It has some advantages over pv serial: - Reliable communication if tcp is used - Migration support for slirp - No new driver in the guest. - Might even work for older guests The disadvantages are: - Need to 'teach' guest daemons/firewalls not to handle/block the new nic - Link local addresses for ipv4 are problematic when using on other nics in parallel - We should either 1. not use link local on other links 2. Use standard dhcp addresses 3. do not use tcp/ip for vmchannel communication. So additional nic can do the job and we have several flavours to choose from. Regards, Dor --------------020802080208030108030604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx2.redhat.com id n0BF7ZEQ015353 Carl-Daniel Hailfinger wrote: 
On 11.01.2009 08:10, Blue Swirl wrote:
  
On 1/11/09, Jamie Lokier <jamie@shareable.org>=
 wrote:
 =20
    
 > But we also have to think about how to support=
 newer platforms and newer
 > kernels and this will often mean that we have to make intrusive cha=
nges
 > so that the integration makes everyone happy.  This does not mean t=
hat
 > we cannot support older platforms though, we just have to do it a l=
ittle
 > differently on the older platforms.

 Sure, but don't make it _deliberately_ hard to support
 older/obscure/can't-compile-a-kernel-module guests by designing
 something that's obviously going to require a totally different
 mechanism on those other guests.  It would make it unnecessarily hard
 to integrate diverse guests with management apps from different
 authors if they do adopt the vmchannel mechanism.
   =20
      
I think a serial port device should be universally sup=
ported by any OS
and it's portable to many systems. Older OS may accidentally enable
forwarding between the trusted nic and other nics, this doesn't happen
with serial lines.
 =20
    

I remember the old days of DOS networking where the Kirschbaum-Netz
software provided some sort of routed/forwarded networking between PCs
over serial ports. It was a default on choice in many corporate and
private "LANs" in Germany at the beginning of the last decade.

Except for machines with that software (which is really hard to get
nowadays), my concern should be a non-issue, especially for virtual
machines which are unlikely to have such software installed.

Regards,
Carl-Daniel

Actually vmchannel started as a pv serial implementation. Standard serial is
a bit low performing and demand an vmexit per byte (maybe it's not that bad for us).
Moreover, various guest do not support more than 4 serial channels. Since there
should be several channels and we like to preserve some for console/debug, it is
not enough.
Originally, vmchannel was a virtio interface with netlink interface to the kernel.
Then, Anthony asked to change it to a socket interface with new address family. It
was indeed a logical step. Then, David Miller was reluctant to add such interface to the
kernel. Instead, he offered the network device solution.
Are we close to begin this loop again?=C2=A0 :)

Let's try to stick to the nic solution. It has some advantages over pv serial:
=C2=A0=C2=A0=C2=A0 - Reliable communication if tcp is used
=C2=A0=C2=A0=C2=A0 - Migration support for slirp
=C2=A0=C2=A0=C2=A0 - No new driver in the guest.
=C2=A0=C2=A0=C2=A0 - Might even work for older guests
The disadvantages are:
=C2=A0=C2=A0=C2=A0 - Need to 'teach' guest daemons/firewalls not to handl= e/block the new nic
=C2=A0=C2=A0=C2=A0 - Link local addresses for ipv4 are problematic when u= sing on other nics in parallel
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 - We should either 1. not use link local = on other links 2. Use standard dhcp addresses 3. do
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 not use tcp/ip for= vmchannel communication.

So additional nic can do the job and we have several flavours to choose from.

Regards,
Dor
--------------020802080208030108030604--