On 13 April 2012 11:24, Paolo Bonzini <pbonz...@redhat.com> wrote: > The PC has a similar model but it is implemented with N+1 devices, one > APIC per CPU plus the IO-APIC. > > For the ARM, it seems cleaner to me to also split it into a per-CPU > object (gic_cpu_ops) and a connection object (gic_dist_ops + > gic_thiscpu_ops)---even if the per-CPU object are just thin forwarders > because the logic is embedded in a single device.
I'm against this because it's not modelling the hardware. The actual silicon is a single block of functionality with a number of configurable knobs/pins/memory regions, and I think trying to impose a boundary that doesn't exist in reality isn't going to work. The only sane forwarding you could do for the gic_cpu_ops objects would be to forward the reads and writes entirely untouched. That's just a silly special case wrapper around a MemoryRegion and I don't see that it helps. Also from the point of view of a user of the GIC (ie the SoC level containers) you don't want to be messing about instantiating lots of different objects and connecting them together. You want to configure and instantiate one object, the GIC, and wire it up in the obvious way: by mapping the memory regions it exposes at the locations you require and by wiring up the irq/gpio lines to your own irq/gpio lines. -- PMM
