Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2

[Peter Maydell <peter.maydell@linaro.org>]

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

-- PMM