On 3 January 2012 13:37, Anthony Liguori<address@hidden> wrote:
For what you're getting at, you actually want to model the CPUs in QOM such
that you would have an ARM926 is-a ARMCPU is-a CPUCommon.
Then you could have the beagle machine have a link<ARM926>. If it always
has a single CPU, you make it a child<ARM926> and the user can't change it.
The CPU should always be a child of the board, surely, even if the user
might want to use a different one? That's just basic composition.
The links should be for "the CPU has two input IRQ lines" and so on.
(Beagle is an A8, incidentally.)
For instance,
in a fully QOM world, trying to run a beagle machine with (say) a 926
CPU should fail to instantiate, because the 926 CPU won't have the right
set of irq/gpio inputs and outputs that the beagle machine needs to
connect up to. (This is the QOM equivalent of trying to ram a 486
into a Pentium CPU socket.)
I don't think we even have syntax for 2 at the moment except for the
weird special case of "-cpu foo".
Yeah, it's still not clear to me how much we want to model CPUs in QOM. We
could do it very simply and flat or model the individual CPUs as proper
types which lets you do fancier things with links.
What I definitely want is that an ARM CPU should look like any other
device in that it has input (and maybe output) GPIO lines, and (for
MP cores) it exposes MemoryRegion(s) that the board (or SOC) maps.
And instantiating and wiring up 926 (a "simple" unicore) should look
pretty much the same at machine model level as wiring up an A9MP
(a "complicated" multicore with built-in peripheral devices, interrupt
controller, etc, which we'd presumably model as a QOM object which
uses composition for all its peripherals and the "actual CPU").