From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWq0b-0002yn-My for qemu-devel@nongnu.org; Tue, 22 May 2012 10:24:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWq0W-0003cG-DG for qemu-devel@nongnu.org; Tue, 22 May 2012 10:24:21 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44858 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWq0W-0003bh-4K for qemu-devel@nongnu.org; Tue, 22 May 2012 10:24:16 -0400 Message-ID: <4FBBA188.8060605@suse.de> Date: Tue, 22 May 2012 16:24:08 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1337682954-20618-1-git-send-email-imammedo@redhat.com> <1337682954-20618-4-git-send-email-imammedo@redhat.com> <4FBB6EFA.5080001@siemens.com> <4FBB89B7.50704@redhat.com> In-Reply-To: <4FBB89B7.50704@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH qom-next 3/5] pc: move apic_mapped initialization into common apic init code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov , Jan Kiszka , Peter Maydell Cc: "aliguori@us.ibm.com" , "ehabkost@redhat.com" , "sw@weilnetz.de" , "mtosatti@redhat.com" , "qemu-devel@nongnu.org" , "blauwirbel@gmail.com" , "avi@redhat.com" , "pbonzini@redhat.com" Am 22.05.2012 14:42, schrieb Igor Mammedov: > On 05/22/2012 12:48 PM, Jan Kiszka wrote: >> On 2012-05-22 07:35, Igor Mammedov wrote: >>> - apic_mapped =3D 1; >>> - } >>> - >>> - /* KVM does not support MSI yet. */ >>> - if (!kvm_irqchip_in_kernel()) { >>> - msi_supported =3D true; >>> - } >>> - >>> - if (xen_msi_support()) { >>> - msi_supported =3D true; >>> - } >>> - >>> - return dev; >>> -} >>> - >> >> You are loosing some xen bits here. But this will collide with latest >> kvm pull request >> (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/91171) anyway. >> You may want to base on uq/master. >> >=20 > This patchset is based on Andreas' qom-next tree. Probably I should wai= t > till above mentioned kvm pull is pulled in and it aprears in qom-next. Jan, we currently have a chaos of concurrent, colliding QOM series. qom-next was intended to resolve this but so far it's a rebasing patch queue on top of master and not a repository with stable hashes so I can't do PULLs myself but I could cherry-pick related patches if needed. Igor, if you put the code movement init -> initfn into its own patch I'll apply it to qom-next right away. Haven't looked at the series in-depth yet. We're not quite there yet with qom-next due to series and counterseries and lack of input on realize/QBus. My current merge plan is as follows: * Apply QOM CPUState series part 3 (cpu_state_reset) - aggressively done last night, prerequisite for part 4. * Apply the last two remaining ARM cpu_reset followup cleanups - waiting for one ack by PMM. * Post QOM CPUState series part 4 (CPU_COMMON) - still fiddling with bisectability, hope to post today. This will show areas of conflicts wrt apic and x86 and is quite invasive (qom-cpu branch on GitHub). * Mix and match patches from Paolo's and Anthony's series for realizefn. Hope to post a short-term compromise soon, leaving properties aside for now. Apply it so that we finally have a realizefn. * Post QOM CPUState series part 5 (CPUState conditionally as device). WIP (qom-cpu-dev branch on GitHub), needed for hotplug IIUC and this will enable integration with machine reset. Doesn't depend on part 4 so f= ar. * Apply PMM's ARM copro series - waiting for acks, still need to carefully review the final CPUID movements. * Post realizefn implementation on top - probably to be merged after PMM's holiday, i.e. to master not to qom-next. * Align part 4 with Igor's series, possibly rebase on part 5. See how close to 1.2 we get and how the review of all open series goes. Whatever progress we make on qom-next, the idea is to have qom-next merged into master *first*, since it's getting really large. Don't know what KVM PULL Jan is referring to - if it's for 1.1 then I'll rebase on it but otherwise I expect series to get rebased onto master w/qom-next before sending a PULL. That's why I asked target maintainers to queue the patches from my part 3 in their queues, to avoid merge conflicts once the 1.2 window opens. For the current QOM series I'm fine rebasing myself so far. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg