From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Merging kvm-apic into qemu-kvm Date: Thu, 26 Jan 2012 16:45:59 +0100 Message-ID: <4F217537.8030202@siemens.com> References: <4F216E19.3040905@redhat.com> <4F217056.1030609@siemens.com> <4F21720A.9040306@siemens.com> <4F2173B7.2040904@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: KVM list , qemu-devel To: Avi Kivity Return-path: Received: from david.siemens.de ([192.35.17.14]:18952 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752133Ab2AZPqH (ORCPT ); Thu, 26 Jan 2012 10:46:07 -0500 In-Reply-To: <4F2173B7.2040904@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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