On 13 April 2012 11:00, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 13/04/2012 11:53, Peter Maydell ha scritto: >> On 13 April 2012 10:32, Paolo Bonzini <pbonz...@redhat.com> 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
