On 3 January 2012 13:37, Anthony Liguori <anth...@codemonkey.ws> 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"). -- PMM
