[Qemu-devel] ARM QOM conversion / class hierarchy

[Peter Maydell <peter.maydell@linaro.org>]

(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...

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