From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLsMD-0000ib-RZ for qemu-devel@nongnu.org; Sat, 10 Jan 2009 23:55:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLsMC-0000iJ-VT for qemu-devel@nongnu.org; Sat, 10 Jan 2009 23:55:29 -0500 Received: from [199.232.76.173] (port=42798 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLsMC-0000iG-PW for qemu-devel@nongnu.org; Sat, 10 Jan 2009 23:55:28 -0500 Received: from mail2.shareable.org ([80.68.89.115]:53653) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LLsMC-0004vl-2M for qemu-devel@nongnu.org; Sat, 10 Jan 2009 23:55:28 -0500 Date: Sun, 11 Jan 2009 04:55:24 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] mark nic as trusted Message-ID: <20090111045524.GB15975@shareable.org> References: <496501CD.8060202@codemonkey.ws> <20090107194633.GB19406@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4968E74E.5040905@codemonkey.ws> Reply-To: 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 Cc: dlaor@redhat.com Anthony Liguori wrote: > You cannot get around having a kernel module to support something like > vmchannel so that's always going to be a requirement. A completely > userspace approach ala the VMware backdoor hackery is just too hideous. Eh? I thought the point of vmchannel is to use the guest network stack, so guest processes - including user ones - can potentially speak over it to the host via a marked, designated channel. If you need a kernel module, i.e. you're doing special kernely things, there's no need for the vmchannel device to be a normal NIC device, no need for it to interfere with the guest networking (e.g. conflicting IPv4 subnets), and it can use virtio, I agree in that case. Now that it's clear I'm imagining guest userspace admin processes and you're imagining a kernel module on the guest, the rest of this exchange makes sense :-) > >In some circles, a major purpose of virtualisation is to run old OS > >versions, either copied from machines where the hardware is aging to > >keep a working system still working, or for compatibility testing. > > When dealing with older OSes, there really no limit in terms of what we > can do. For instance, there's no reason that the backported version of > the virtio-net driver cannot expose a chardev interface if the distro > doesn't have the appropriate configuration. Realistically, the set of (older) OSes where you'd like to run simple guest-host communicating apps for VM management, especially simple monitoring apps (load avg, memory use, number of processes), is much larger than those older OSes which virtio-net can be loaded onto. E.g. Linux and Windows apps to do that could run on very old/obscure versions and diverse distributions, if statically linked. Sometimes there'll be no backport of kernel drivers, and if there is one, that doesn't mean you can load it into an existing guest image or even compile it for that exact guest kernel. I think it's quite reasonable to want to run simple monitoring apps on such guests. > 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. -- Jamie