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

[Blue Swirl]

On Fri, Apr 13, 2012 at 09:32, Paolo Bonzini <address@hidden> wrote:
> 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.

Actually there were two different TCX devices, standard 8 bit model
and more expensive 24 bit version. The 24 bit version was downwards
compatible, it had a separate control plane where you could select for
each pixel whether it used 8 bit mode or 24 bit mode. The 24 bit plane
data resided also in a separate region to 8 bit data. In the 8 bit
version these regions did not exist.

We could make the devices separate, then the depth would be fixed per
device but the memory regions would not change. At sun4m.c we could
choose the device based on the depth. Because we also pass the depth
to OpenBIOS  (it uses that to determine the device type), everything
should work as before.

> 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
>