Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()

[Paolo Bonzini]

Il 13/04/2012 11:09, Peter Maydell ha scritto:
> On 13 April 2012 09:33, Paolo Bonzini <address@hidden> wrote:
>> Il 13/04/2012 10:12, Peter Maydell ha scritto:
>>> Half a dozen from random grep:
>>> "xilinx,timer" -- memory region size depends on a property
>>> "lan9118" -- which MemoryRegionOps we use for the region depends
>>>   on the "mode_16bit" property.
>>
>> You can set these at realize time, before the memory region itself is
>> realized (realization uses pre-order for this reason).
>>
>>> "SUNW,tcx" -- number of memory regions depend on depth property
>>
>> The regions can still exist in the device, whether they're mapped
>> depends on the depth property.
> 
> This is like saying that you should still have 512 IRQ lines on
> every IRQ array, or that omap should have 6 GPIO modules even
> on variants with only 4, and so on.

As far as I understood, the fact that you cannot change the depth
of this particular framebuffer is a limitation of QEMU.  The
framebuffer can do both 8 and 24-bit, the current model is the wrong
one.

The ARM cases are more interesting.

>>> "a9mpcore_priv" (and its equivalents for a15, 11mpcore, etc)
>>> "arm_mptimer" -- number of regions and irqs depends on 'num-cpu' prop
>>
>> Why wouldn't you model this as a parent SoC object with either:
>>
>> - 1 GIC child, N CPU children, N MPTimer children, and N GICInterface
>> children (with links to the GIC);
>>
>> - or 1 GIC + N CPU children, each of the latter having 1 MPTimer child
>> and 1 GICInterface child (with links to the GIC);
> 
> You're right in general that we should be modelling these as
> container objects (I posted a series the other week that starts
> to move in that direction by dropping the weird subclassing of
> the GIC.) But the overall container object for a cortex-a9 will
> still be an object whose number of exposed IRQ lines depends on
> a device parameter

Yes, that would require a little more coding, just like the grlib.

> , and the GIC device must still have a number
> of exposed memory regions/input lines/output lines that depends
> on the number of CPUs, which is going to be a device parameter.

That would be a device parameter of the SoC.  As long as the GIC
is only created after the device parameter has been set on the
parent, it can just read it from there.

(BTW perhaps it is cheating, but on the PC you just have
"-smp 4" for a four-core so it's not a device property).

> I'm not sure what your GICInterface children are?

Those would model the GIC<->CPU interface memory regions.

    for (i = 0; i < NUM_CPU(s); i++) {
        s->backref[i] = s;
        memory_region_init_io(&s->cpuiomem[i+1], &gic_cpu_ops, &s->backref[i],
                              "gic_cpu", 0x100);
    }

Paolo