From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LL3hE-0001sN-G0 for qemu-devel@nongnu.org; Thu, 08 Jan 2009 17:49:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LL3hC-0001q2-FJ for qemu-devel@nongnu.org; Thu, 08 Jan 2009 17:49:47 -0500 Received: from [199.232.76.173] (port=38952 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LL3hC-0001px-6U for qemu-devel@nongnu.org; Thu, 08 Jan 2009 17:49:46 -0500 Received: from mail2.shareable.org ([80.68.89.115]:59602) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LL3hB-0002TO-Pb for qemu-devel@nongnu.org; Thu, 08 Jan 2009 17:49:45 -0500 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1LL3h8-0003S0-Se for qemu-devel@nongnu.org; Thu, 08 Jan 2009 22:49:42 +0000 Date: Thu, 8 Jan 2009 22:49:42 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] mark nic as trusted Message-ID: <20090108224942.GA12848@shareable.org> References: <4964D98B.6030404@codemonkey.ws> <20090107165050.GI3267@redhat.com> <4964EC2B.1080406@codemonkey.ws> <4964EC55.4000507@codemonkey.ws> <20090107184103.GA19406@redhat.com> <496501CD.8060202@codemonkey.ws> <20090107194633.GB19406@redhat.com> <49665AE7.3000708@codemonkey.ws> <20090108212652.GB22504@redhat.com> <49667330.5070001@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49667330.5070001@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 Anthony Liguori wrote: > Are we going to have a standard way of doing this in Linux distros such > that these nics are treated differently from other nics? Have we gotten > the appropriate distro folks to agree to this? That wouldn't work for older distros and Windows anyway. But you might reasonably want to run apps doing guest-host communication on older guest distros too, simply as an app, not requiring guest customisation. Is there some way to mark a PCI device so it will be ignored at boot time generically? Changing the PCI ID will do that for all guests, but is it then feasible for the vmchannel guest admin software to bind a NIC driver to a non-standard PCI ID, on the major OSes? Suppose you start a guest with two "trusted" nics, because you want to run two unrelated vmchannel-using admin apps. How does each app know which nic to use - or do they share it? As the guest OS's TCP is being used, what do you do about IP address space conflicts? I.e. if NIC #1 is the guest's LAN, and NIC #2 is the vmchannel, how is the vmchannel NIC going to be configured in a way that's guaranteed to avoid breaking the LAN networking, which could be assigned any legal subnet (especially when bridging is used), and on some networks changes from time to time? Perhaps vmchannel will only use IPv6, so it can confidently pick a unique link-local address? -- Jamie