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

[Peter Maydell]

On 13 April 2012 11:00, Paolo Bonzini <address@hidden> wrote:
> Il 13/04/2012 11:53, Peter Maydell ha scritto:
>> On 13 April 2012 10:32, Paolo Bonzini <address@hidden> wrote:
>>> Il 13/04/2012 11:09, Peter Maydell ha scritto:
>>>> 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.
>>
>> Well, if we can do it then that's fine (assuming that the actual
>> implementation doesn't look too dreadful and doesn't look wildly
>> different from "number of irq lines is fixed").
>
> Dreadful, no.  Different, no idea as of now. :)
>
>>>> , 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.
>>
>> I don't understand how this would work? The GIC can't read
>> parameters from its parent, surely, that would be breaking
>> encapsulation.
>
> The GIC can have a (strongly-typed) backlink to the SoC, and can call
> object_property_get on it.

The trouble with this is that the GIC is embedded into about
half a dozen different parent devices, all of which obviously
have different types. And having an otherwise self-contained
GIC object have a random backlink out to the SoC purely for
purposes of finding something out about the component that's
using it *is* breaking encapsulation, even if it's a strongly
typed backdoor...

>>> (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 am assuming that '-smp 4' will eventually convert into
>> setting a device property on something (probably on the
>> QOM object which corresponds to the top level machine?).
>
> Yeah, you would still know the type of that object though, and you would
> still be able to retrieve the property.
>
>>>> I'm not sure what your GICInterface children are?
>>>
>>> Those would model the GIC<->CPU interface memory regions.
>>
>> MemoryRegions model memory regions :-) I'm not sure what
>> more there is to do there.
>
> MemoryRegion + how to create them + ops != MemoryRegion. :)

Er, the ops are part of the core GIC -- what we're modelling
here is a memory-mapped set of registers which provide a
window (interface) onto the device. That's exactly what
exposing a MemoryRegion is. (I'd like to have better support
for exposing "named" MemoryRegions, in the same way that
a Pin to me is support for "named" irq/gpio lines, but I don't
think that's what you're getting at.)

-- PMM