qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?


From: Peter Maydell
Subject: Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
Date: Fri, 21 Oct 2011 07:58:54 +0100

On 20 October 2011 23:51, Andreas Färber <address@hidden> wrote:
> I have now come across such a heterogeneous SoC myself: Renesas announced
> the R-Car H1 this week, a SoC with one SH4A core and four ARM Cortex-A9
> cores.

Does it expose the SH4 to apps/OSes, or is it mostly used for
power management or similar ignorable duties? (For several
of the ARM boards we currently just ignore the fact that the real
h/w has a Cortex-M3 doing power management type stuff.)

> That would make them all 32-bit, and I am hoping to get confirmation
> that this is consistently Little Endian.

I think the endianness is a red herring for heterogenous systems
anyway -- what QEMU defines as the target endianness is really something
more like the "system bus endianness", as far as I can tell.
An extra core with a different idea of endianness shouldn't be
any harder to handle than cores which can switch endianness
at runtime. You just either insert swizzling or not.

> The only realistic way to get started with such setups I see is to create a
> new target-xxx for the specific mix, define TARGET_LONG_BITS etc.
> appropriately in a new cpu.h, compile the needed target-xyz/*.c to unique
> xxx-softmmu/xyz-*.o and dispatch from a cpu_init() to the two cpu_*_init().

Yuck. Longer term if we want to support this kind of heterogeneity
we should be removing all the compile-time assumptions and generally
making the target-specifics suitably contained rather than leaking
into the rest of the code.

> I'm guessing we may need to distinguish the TBs at runtime? Reserving
> log2(#architectures) bits in the TBFLAGS might do, but feels ugly.
> Probably a lot of other issues I'm not seeing yet.

We may want the tb cache to be per-core anyway (and one thread per core),
which would avoid the problem of trying to wedge everything into one set
of tb_flags.

(Has anybody had a look at http://sourceforge.net/p/coremu/home/Home/ ?)

-- PMM



reply via email to

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