From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 00/20] qemu-kvm: Cleanup and switch to upstream - The Season Final Date: Sun, 29 May 2011 19:24:39 +0300 Message-ID: <4DE27347.7080101@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44124 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752761Ab1E2QYr (ORCPT ); Sun, 29 May 2011 12:24:47 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 05/27/2011 03:19 PM, Jan Kiszka wrote: > With this series applied, we are finally at a level of almost zero > redundancy between QEMU upstream and the qemu-kvm tree. The last major > duplication to be removed is the original io-thread implementation and > everything related to it: > - locking > - vcpu wakeup/kicking as well as suspend/resume > - on-vcpu execution > - io-thread loop > - vcpu thread loop > > The approach taken here is similar to what was done to morph KVM core > functions into upstream code: First all to be converted code is moved > over into cpus.c, then qemu-kvm's functions are gradually changed and > replaced with the upstream versions. > > This means that we have to enable CONFIG_IOTHREAD which is so far > incompatible with qemu-kvm. This incompatibility causes a temporary > breakage of the TCG mode early in the series, but it is healed again > with the last patch applied. > > To make it clear: Even with all this applied, there is still a lot to > do to turn upstream QEMU into the primary KVM platform. We need to > - rework in-kernel IOAPIC/PIC/APIC/PIT support, namely > - proper qdev modeling > - new MSI hooking architecture (half-done) > - VAPIC support (haven't looked at details yet, maybe just cleanups) > - prepare device assignment for upstream (VFIO and/or KVM-based) > - clean up remaining small deltas (including posix-aio-compat...) > - get rid of legacy command line interfaces (e.g. via deprecation > warning in release X and removal in X+n, n>= 1) > > But then we are really done and can all retire. ;) > > In the meantime, please review/merge these bits. Looks good. I really appreciate this effort, it's removing a huge thorn in our feet. -- error compiling committee.c: too many arguments to function