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

[Michael Roth]

On Tue, Mar 20, 2012 at 12:12:45PM +0000, Peter Maydell wrote:
> (I can't find the relevant patches in the mailing list at
> this point. I'm talking about this tree from Andreas:
> http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-cpu-arm )
> 
> So in an IRC discussion yesterday we didn't seem to make much headway
> on what the right class hierarchy is here. There seem to be two basic
> options:
> 
> (1) subclass per CPU type
> This is what Andreas' tree does at the moment, so there's an ARMCPU
> which is a subclass of CPUState, and then a lot of subclasses of
> that, one per CPU ("arm926", "arm1026", "cortex-a8", "cortex-a9", etc).
> Mostly these subclasses just arrange for different reset values for
> various registers, setting feature bits, etc.
> 
> (2) no subclasses for CPU types
> This approach would just have a single ARMCPU, and then -cpu foo
> is syntactic sugar for setting a lot of qom properties.
> 
> 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...

Rather than key off an ID you could also just break
implementation-specific functionality out into a set of interfaces you
implement/override as part of the objects' initialization. Same ends, and
still fits the model pretty nicely, assuming the functionality is all
derivable from the common base-class.

> 
> Regardless, it seems to me that we ought to be doing this the
> same way for all our target CPUs. I don't know whether mips/x86/
> etc have any preference one way or the other.
> 
> -- PMM
>