From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH 00/20] qemu-kvm: Cleanup and switch to upstream - The Season Final Date: Tue, 31 May 2011 10:36:12 -0300 Message-ID: <20110531133612.GD7400@amt.cnet> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33596 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751701Ab1EaNgX (ORCPT ); Tue, 31 May 2011 09:36:23 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Fri, May 27, 2011 at 02:19:04PM +0200, 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. Applied, thanks.