From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SX7hU-0003j9-Da for qemu-devel@nongnu.org; Wed, 23 May 2012 05:17:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SX7hP-0003cU-AD for qemu-devel@nongnu.org; Wed, 23 May 2012 05:17:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SX7hP-0003bx-2e for qemu-devel@nongnu.org; Wed, 23 May 2012 05:17:43 -0400 Message-ID: <4FBCAB30.708@redhat.com> Date: Wed, 23 May 2012 11:17:36 +0200 From: Igor Mammedov 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> <4FBBA188.8060605@suse.de> In-Reply-To: <4FBBA188.8060605@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Peter Maydell , "aliguori@us.ibm.com" , "ehabkost@redhat.com" , Jan Kiszka , "mtosatti@redhat.com" , "qemu-devel@nongnu.org" , "blauwirbel@gmail.com" , "avi@redhat.com" , "sw@weilnetz.de" , "pbonzini@redhat.com" On 05/22/2012 04:24 PM, Andreas F=E4rber wrote: > 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. >>> >> >> This patchset is based on Andreas' qom-next tree. Probably I should wa= it >> 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. I'll split this patch in apic and cpu parts and repost with fixes for iss= ues Jan and Peter spotted. > > 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 don= e > last night, prerequisite for part 4. > > * Apply the last two remaining ARM cpu_reset followup cleanups - waitin= g > 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 wr= t > 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= far. > > * 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 ----- Igor