qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v1 1/2] arm: Add the cortex-a9 CPU to the a9mpcore


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC v1 1/2] arm: Add the cortex-a9 CPU to the a9mpcore device
Date: Mon, 16 Jun 2014 21:22:13 +1000

On Mon, Jun 16, 2014 at 9:11 PM, Peter Maydell <address@hidden> wrote:
> On 16 June 2014 11:58, Andreas Färber <address@hidden> 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.
>

+1. Either you have an MPCore package as part of your soc or
standalone CPU. Both are valid instantiables on the SoC level.

Regards,
Peter

> thanks
> -- PMM
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]