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

[Paolo Bonzini]

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