From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M8bbN-0002ST-MI for qemu-devel@nongnu.org; Mon, 25 May 2009 10:56:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M8bbI-0002PM-Pw for qemu-devel@nongnu.org; Mon, 25 May 2009 10:56:33 -0400 Received: from [199.232.76.173] (port=36620 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M8bbI-0002PJ-Jg for qemu-devel@nongnu.org; Mon, 25 May 2009 10:56:28 -0400 Received: from mx2.redhat.com ([66.187.237.31]:47756) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M8bbH-00059V-R4 for qemu-devel@nongnu.org; Mon, 25 May 2009 10:56:28 -0400 Message-ID: <4A1AB196.10008@redhat.com> Date: Mon, 25 May 2009 17:56:22 +0300 From: Avi Kivity MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Need a new plan on adding kvm support to qemu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori , Jan Kiszka Cc: qemu-devel , KVM list While I appreciate the efforts to add clean qemu/kvm integration in upstream, it's driving me mad. Every merge I'm faced with regressions (mostly due to changing code, not to upstream breakage) and need to fix things. Work done during merges is very likely to contain errors since there's no incremental change to review and test. We now have two very different kvm implementations: The upstream implementation: - mostly clean - crippled - no smp - no kernel irqchip - no kernel pit - no device assignment - reduced support for older host kernels - no ia64 support - no nmi support - no tpr patching - almost totally untested (small userbase) The downstream implementation: - a tangled mess - featureful and performant #include - heavily tested (kvm-autotest, large kvm userbase, inclusion in distros) What we have here is the classic rewrite fallacy (rewriting from scratch is easier than fixing, now six months into the voyage with no end in sight) coupled with inflicting pain to the largest contributor to qemu (I mean the kvm community, not me personally). Meanwhile, new kvm kernel features need to be implemented twice in userspace. I propose that we stop this. It is fragmenting the development effort, causing regressions (again, mostly through merge issues, but also through new code duplicating old code incorrectly), and not really helping upstream qemu. It's also the first case I've heard of where a project competes with itself (well not really but it's a nice soundbite). As a first step I've merged a copy of libkvm into qemu linkage (i.e. not as a library), so we can start to use the upstream code (say, use kvm_ioctl() from libkvm.c). It's not going to be easy, but what we have now isn't working. -- error compiling committee.c: too many arguments to function