On 16 June 2014 11:58, Andreas Färber <afaer...@suse.de> wrote: > Well, for Cortex-A9 that may work. But Cortex-A15 (and Cortex-A5x if > existant by now) should also be refactored alongside, as proof of > concept - can you really create num_cpu cortex-a15 CPUs on the MPCore > for a big.LITTLE configuration? I'd be really surprised if there were > separate MPCore devices per cluster. That would then indicate that the > homogeneity assumption among CPUs within an MPCore is wrong and we need > to let its parent create the CPUs rather than an MPCore property.
Not sure what the relevance of big.LITTLE is here -- QEMU simply doesn't support heterogenous CPU configurations so we can't model big.LITTLE at all. If we did, it would be via having a SoC with one a15mpcore and one a7mpcore. (This is how the hardware does it -- there are two multicore clusters, plus some cache coherency interconnect magic.) > Besides, not all CPUs have an MPCore, Cortex-A8 and Cortex-A5 come to > mind, so we should be aware that ARMCPU child<>s on the MPCore will lead > to asymmetry between SoCs. For the A8 and A5 the SoC object would just instantiate them directly -- there's no equivalent in the hardware of the "n CPUs and their private devices" layer. So I think any asymmetry between SoCs in QEMU is just a reflection of the differences in the hardware. thanks -- PMM
