From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v4 00/15] uq/master: Introduce basic irqchip support Date: Thu, 15 Dec 2011 12:59:55 +0100 Message-ID: <4EE9E13B.5040106@siemens.com> References: <20111212163725.GA32142@amt.cnet> <4EE63123.101@siemens.com> <4EE9CD09.3000901@siemens.com> <4EE9DFDB.4050304@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" , qemu-devel , Anthony Liguori , "Michael S. Tsirkin" , Blue Swirl , Lai Jiangshan To: Avi Kivity Return-path: Received: from thoth.sbs.de ([192.35.17.2]:25103 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756143Ab1LOMAS (ORCPT ); Thu, 15 Dec 2011 07:00:18 -0500 In-Reply-To: <4EE9DFDB.4050304@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-12-15 12:54, Avi Kivity wrote: > 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? qemu-kvm will carry the new upstream bits but will keep them widely disabled until upstream is feature equivalent. Of course, merging the kvm-irqchip-merge only makes sense once the corresponding upstream queue was actually merged. > Sounds like it'll be pretty easy to resolve the conflicts if so. > Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux