Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

On 2012-01-26 16:39, Avi Kivity wrote:
> On 01/26/2012 05:32 PM, Jan Kiszka wrote:
>> On 2012-01-26 16:25, Jan Kiszka wrote:
>>> On 2012-01-26 16:15, Avi Kivity wrote:
>>>> The changes to kvm-apic are so drastic, that merging them into qemu-kvm
>>>> in the normal way won't work.  I can consider just dropping the existing
>>>> implementation and switching to the new one, but the comment at the end
>>>>
>>>>     Make the basic in-kernel irqchip support selectable via
>>>>     -machine ...,kernel_irqchip=on. Leave it off by default until it can
>>>>     fully replace user space models.
>>>>
>>>> suggests that things are still missing.
>>>>
>>>> Jan, what's still missing?
>>>
>>> - in-kernel PIT (patches done, waiting for some upstream bits to be
>>>   merged first)
>>> - TPR acceleration via VAPIC (WIP)
>>> - MSI support
>>>
>>> The latter is the big chunk. It requires quite some
>>> refactoring/enhancement of the MSI layer. I posted the first version
>>> last year. We need to agree on the design, then probably switch qemu-kvm
>>> over while pushing generic bits upstream. And then we can extend the
>>> upstream in-kernel *PIC using that new interfaces. Once upstream works
>>> with MSI, we can switch qemu-kvm over, leaving basically only
>>> device-assignment as the last missing bit.
>>>
>>>>  Any idea on how to proceed?
>>>
>>> I had a qemu-kvm branch here that disables the upstream in-kernel *PIC
>>> in favor of its current version. I still need to refresh that work (was
>>> based on an earlier revision), but it was not that horrible. Let me check...
>>
>> It's online, see
>> http://git.kiszka.org/?p=qemu-kvm.git;a=shortlog;h=refs/heads/kvm-irqchip-merge
> 
> You're a hero.
> 
>> I merged the upstream patches one by one, resolving the mechanical and
>> logical conflicts in each step. Was done for that backend/frontend
>> concept, but the adjustments should basically be the same now. Want me
>> to prepare a branch or will you do this?
> 
> It's much more likely that you'll get it right - I started to do this
> but backed out.
> 
> btw, the branch doesn't appear to be merges, so I'll still have huge
> conflicts at the end.  If you do this with real merges, git will
> recognize it and just adopt your version.

I will try to use your concept: pull in upstream commits into a merge
branch as long as there is a mechanical or logical conflict. Will then
publish the branch for pulling. Can I start at the current 'next' head?

Jan

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