Re: [Qemu-devel] ARM QOM conversion / class hierarchy

[Peter Maydell]

On 20 March 2012 14:08, Paul Brook <address@hidden> wrote:
>> Option two looks kind of nice, but I'm not sure whether it would
>> actually work. I think you could do 95% of what you need for a
>> different CPU that way (lots of properties for "value of ID_MMFR1",
>> "value of "ID_MMFR2", "reset value of SCTLR", etc etc, plus properties
>> for all our existing ARM_FEATURE_*, and some new ones where we're
>> currently keying off "which CPU is this?" rather than using a feature
>> bit, or just failing to distinguish things which aren't really
>> common to all CPUs). But I'm not sure how you'd handle the genuinely
>> implementation specific cp15 registers (eg cp15 crn=15). We could
>> have a property which says "is this a 926/1026/1176/A8/A9/..." (or
>> equivalently, key off the relevant fields of the main ID register) but
>> it doesn't seem very OO-like to have one class whose behaviour changes
>> based on an integer that's basically defining an ad-hoc sub-type...
>
> IIUC the "proper OO" solution to this requires multiple inheritance, which we
> don't have.  The problem with subtyping is we can use it for at most one
> characteristic.  Everything else ends up being pushed into a common base class
> and controlled by feature bits (or equivalent).

> If we're going to use the class hierachy to implement functionality then there
> are other candidates.  Given the primary purpose of QOM is [IMO] to handle
> interaction between devices, the external interface exposed by the core seems
> like a better candidate for subclassing.  i.e. conventional ARM cores with IRQ
> and FIQ inputs[1] v.s. M profile devices where the core exception model is
> intimately tied to the interrupt controller.

Yes, I think I'd agree there. So should we just have an init function
that provides the implementation-specific cp15 registers based on the value
provided in the QOM property for the main ID register?

> [1] This still applies to things like the Cortex-A9.  In practice ARM may sell
> you an SMP "cluster", but logically it's still a couple of normal cores and an
> interrupt controller.

Yes, this should be implemented by object composition (ie QOM child objects
inside a container). The lines blur rather with the A15, though, where for
instance the generic timer hangs off cp15 but injects interrupts into the GIC,
not directly into the core. (And even for the A9 the coupling is pretty close,
for instance the BE8 byte-swapping, which you might think is a property of the
core, doesn't apply to accesses to the private peripherals (timers, gic, etc).)

-- PMM