From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHtm9-0003xq-FE for qemu-devel@nongnu.org; Tue, 19 Mar 2013 06:28:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHtm7-0003Yo-EB for qemu-devel@nongnu.org; Tue, 19 Mar 2013 06:28:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHtm7-0003YT-6s for qemu-devel@nongnu.org; Tue, 19 Mar 2013 06:28:11 -0400 Message-ID: <51483DAB.4040101@redhat.com> Date: Tue, 19 Mar 2013 11:27:55 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1363628125-5310-1-git-send-email-pbonzini@redhat.com> <5147572E.8040501@redhat.com> <51475A00.8070304@redhat.com> <5147738F.7070803@redhat.com> <51482F56.4070604@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "Edgar E. Iglesias" , qemu-devel@nongnu.org, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Richard Henderson Il 19/03/2013 11:10, Peter Maydell ha scritto: > On 19 March 2013 09:26, Paolo Bonzini wrote: >> Il 18/03/2013 21:21, Peter Maydell ha scritto: >>> On 18 March 2013 20:05, Paolo Bonzini wrote: >>>> Il 18/03/2013 19:17, Peter Maydell ha scritto: >>>>>>> Shouldn't these containers also host the CPU device(s), rather than the >>>>>>> boards? And create them according to the num-cpu property? If so, they >>>>>>> would have to go in hw/arm. >>>>> Yes, ideally they should have the CPU devices in them too. >>>>> Remind me why devices which instantiate the CPU device go >>>>> in hw/arm ? >>>> >>>> Because they refer to ARMCPU/CPUARMState. >>> >>> Well, a container object that instantiated the CPUs wouldn't >>> be referring to the internal CPU state struct, it would just >>> be treating them as QOM objects like any other, so that doesn't >>> apply. >> >> Wouldn't it also bridge the CPU's internal interrupt pins to the GIC? >> Like this code in highbank.c: >> >> >> /* This will become a QOM property eventually */ >> irqp = arm_pic_init_cpu(cpu); >> cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ]; >> ... >> for (n = 0; n < smp_cpus; n++) { >> sysbus_connect_irq(busdev, n, cpu_irq[n]); >> } > > Well, for the CPU to be a proper QOM object it should be exposing > the IRQ/FIQ lines normally, not via the code in hw/arm/pic_cpu.c. That applies to everything else that was put in hw/ARCH. Everything could become a QOM property. > My point is that the QOM abstraction should encapsulate the CPU > cores just like any other piece of hardware. We're not there yet > but that's where we should be going. You can't really put the > CPUs into the a9mpcore &c containers until we've done that > abstraction properly anyway. Why not? It would remove a bunch of code that is currently duplicated in the boards. Paolo