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

[Avi Kivity]

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.

-- 
error compiling committee.c: too many arguments to function