From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb9tC-0001Ti-38 for qemu-devel@nongnu.org; Thu, 15 Dec 2011 06:54:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rb9t7-0007kd-U3 for qemu-devel@nongnu.org; Thu, 15 Dec 2011 06:54:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12475) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb9t7-0007k6-NQ for qemu-devel@nongnu.org; Thu, 15 Dec 2011 06:54:13 -0500 Message-ID: <4EE9DFDB.4050304@redhat.com> Date: Thu, 15 Dec 2011 13:54:03 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20111212163725.GA32142@amt.cnet> <4EE63123.101@siemens.com> <4EE9CD09.3000901@siemens.com> In-Reply-To: <4EE9CD09.3000901@siemens.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: Jan Kiszka Cc: Anthony Liguori , Lai Jiangshan , "kvm@vger.kernel.org" , "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl On 12/15/2011 12:33 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. > > Done yesterday, still seems to work fine. The result can be found at > > git://git.kiszka.org/qemu-kvm.git kvm-irqchip-merge > > The integration of the upstream irqchip patches was, as expected, not > that hard. But the merge of my earlier refactorings, the > backend/frontend split-up caused some efforts. > > I'm not sure what to do with that branch. We could either try to merge > it before pulling in an upstream version that includes the new irqchips. > But that won't work without manual conflict resolution as well. Or the > branch can serve as a reference for re-doing a merge later on. If we merge this before upstream, will the two sides end up equivalent? Sounds like it'll be pretty easy to resolve the conflicts if so. -- error compiling committee.c: too many arguments to function