[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 00/15] uq/master: Introduce basic irqchip sup

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v4 00/15] uq/master: Introduce basic irqchip support
Date: Thu, 15 Dec 2011 12:59:55 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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.


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

reply via email to

[Prev in Thread] Current Thread [Next in Thread]