From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLuT1-0006UI-Sr for qemu-devel@nongnu.org; Sun, 11 Jan 2009 02:10:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLuSz-0006U6-KS for qemu-devel@nongnu.org; Sun, 11 Jan 2009 02:10:38 -0500 Received: from [199.232.76.173] (port=45083 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLuSz-0006U3-Ga for qemu-devel@nongnu.org; Sun, 11 Jan 2009 02:10:37 -0500 Received: from mail-bw0-f12.google.com ([209.85.218.12]:52442) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LLuSy-0008E4-QH for qemu-devel@nongnu.org; Sun, 11 Jan 2009 02:10:37 -0500 Received: by bwz5 with SMTP id 5so19977412bwz.10 for ; Sat, 10 Jan 2009 23:10:34 -0800 (PST) Message-ID: Date: Sun, 11 Jan 2009 09:10:34 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] mark nic as trusted In-Reply-To: <20090111045524.GB15975@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> 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 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. About the overall idea of host marking something as trusted, here are some alternative ideas: - guest could ask for a trusted channel and then the host would create one - guest could ask the host to list the trusted devices - on guest's request, host can cut an existing device from outside world and start using that as the trusted one