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"). >> , 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. > (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?). >> 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. -- PMM
