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

[Andreas Färber]

Am 26.05.2011 um 21:11 schrieb Blue Swirl:

> On Wed, May 25, 2011 at 10:20 PM, Peter Maydell
> <address@hidden> wrote:
> > On 25 May 2011 19:44, Greg McGary <address@hidden> wrote:
> > > I would like to create a QEMU model of an SoC that has several
> > > CPU cores having different architectures.  I'm guessing this
> > > can be done.
> >
> > It's not supported currently as far as I'm aware. There was
> > at least one paper at the QEMU Forum earlier this year describing
> > an approach to multi-CPU environments (embedding QEMU into a
> > SystemC world) that basically saved and restored all QEMU's
> > global variables every time it switched cores...
> >
> > It would be good if it was supported in QEMU proper, but I
> > suspect you may be in for some large-scale restructuring work.
>
> One of the long standing goals for QEMU has been to be able to use a
> single executable to emulate multiple architectures. I think for
> example the lines like
> #define cpu_init cpu_sparc_init
> #define cpu_exec cpu_sparc_exec
> etc. stand for this purpose, so there has been some consideration  
> for this.

Gary never followed up on this, it seems.

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

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().

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.

Comments?

Andreas