Il 19/03/2013 11:10, Peter Maydell ha scritto: > On 19 March 2013 09:26, Paolo Bonzini <pbonz...@redhat.com> wrote: >> Il 18/03/2013 21:21, Peter Maydell ha scritto: >>> On 18 March 2013 20:05, Paolo Bonzini <pbonz...@redhat.com> 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