From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ILgOF-0007t3-Gp for qemu-devel@nongnu.org; Thu, 16 Aug 2007 10:31:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ILgOC-0007qv-OV for qemu-devel@nongnu.org; Thu, 16 Aug 2007 10:31:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ILgOC-0007qh-JH for qemu-devel@nongnu.org; Thu, 16 Aug 2007 10:31:56 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ILgOC-0002BJ-4u for qemu-devel@nongnu.org; Thu, 16 Aug 2007 10:31:56 -0400 From: Paul Brook Subject: Re: [Qemu-devel] merging kqemu into mainline kernel? Date: Thu, 16 Aug 2007 15:31:51 +0100 References: <200708161449.15732.paul@codesourcery.com> <779506c70708160702v52d1305u8d513b1dc9a81c98@mail.gmail.com> In-Reply-To: <779506c70708160702v52d1305u8d513b1dc9a81c98@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708161531.52249.paul@codesourcery.com> 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 > > Mainly because the kernel already has one perfectly good virtualization > > interface. There's very little motivation to add another incompatible > > one, especially when the implementation is known to be fundamentally > > flawed, and probably insecure. > > > > If you really want to get it merged I suggest modifying kqemu to use the > > kvm interface, augmenting the kvm interface if necessary. > > Are you referring to the API when you say interface, or the > functionality itself? If the former that's a reasonable argument, but > the latter is not valid since KVM requires a VT or AMD-V-capable > processor, right? KQEMU does not, and therefore [today] works on a > much larger installed base of hardware. Yes, I mean the API. However in practice you'd probably want to try and share the implementation as well. In short it's likely to need rewriting before it's acceptable upstream. Paul P.S. Please don't top-post. Consider this your final warning.