From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ra9uM-0002u4-Ox for qemu-devel@nongnu.org; Mon, 12 Dec 2011 12:43:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ra9uL-0005nZ-Fp for qemu-devel@nongnu.org; Mon, 12 Dec 2011 12:43:22 -0500 Received: from david.siemens.de ([192.35.17.14]:28252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ra9uL-0005nQ-3c for qemu-devel@nongnu.org; Mon, 12 Dec 2011 12:43:21 -0500 Message-ID: <4EE63D13.9070807@siemens.com> Date: Mon, 12 Dec 2011 18:42:43 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20111212163725.GA32142@amt.cnet> <4EE63123.101@siemens.com> <4EE63BCA.9040204@redhat.com> In-Reply-To: <4EE63BCA.9040204@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 00/15] uq/master: Introduce basic irqchip support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Lai Jiangshan , "kvm@vger.kernel.org" , "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl On 2011-12-12 18:37, Avi Kivity wrote: > On 12/12/2011 06:51 PM, Jan Kiszka wrote: >>> >>> Any thoughts on the qemu-kvm merge plan? Sounds painful. >> >> Pain will be where the existing qemu-kvm extensions collide with these >> refactored upstream devices (backend/frontend split specifically). >> That's where we have to merge very carefully. Haven't tried this yet, >> will give it a spin tomorrow or so. >> >> From that point on, disabling the new stuff for now and at some point >> switching over from the old one should be simple again. >> >> BTW, PIT+HPET+speaker will cause similar issues for the same reasons. >> > > It's a little late for this, but refactoring qemu-kvm in-tree and then > splitting it into patches would have been easier. Let's try it this way > for the next batch. I thought about this, but it definitely takes a clean, qemu-kvm free base as start. The point is to design something free of all the legacy, only looking at the other code base to extract the logic. Moreover, there was and still is quite some upstream cleanup necessary, and that never goes well with the delta of qemu-kvm. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux