From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LM2Kd-00057D-VG for qemu-devel@nongnu.org; Sun, 11 Jan 2009 10:34:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LM2Kc-00055R-DJ for qemu-devel@nongnu.org; Sun, 11 Jan 2009 10:34:31 -0500 Received: from [199.232.76.173] (port=45157 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LM2Kc-00055M-87 for qemu-devel@nongnu.org; Sun, 11 Jan 2009 10:34:30 -0500 Received: from fk-out-0910.google.com ([209.85.128.191]:44055) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LM2Kb-0001yC-IQ for qemu-devel@nongnu.org; Sun, 11 Jan 2009 10:34:29 -0500 Received: by fk-out-0910.google.com with SMTP id 18so5338315fks.2 for ; Sun, 11 Jan 2009 07:34:28 -0800 (PST) Message-ID: Date: Sun, 11 Jan 2009 17:34:28 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] mark nic as trusted In-Reply-To: <496A0B4C.7000004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <496501CD.8060202@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> <496A0B4C.7000004@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com, qemu-devel@nongnu.org On 1/11/09, Dor Laor wrote: > > 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. There could be similar OS limits for number of nics in the system. > 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? :) I propose to make the vmchannel connect to any capable device (serial, nic, usb, IO port, whatever) by adding some indirection. Moreover, at start no device should be "vmchannel-enabled" but the connection could be made dynamically at guest's request, then some of the disadvantages you listed are gone. > 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 The guest could request a vmchannel only after ensuring that the firewall is fixed.. > - Link local addresses for ipv4 are problematic when using on other > nics in parallel Likewise, the guest could check the address situation beforehand. > - 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. The solution should be generic enough so that any nic can be connected to vmchannel.