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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
