Re: [Qemu-devel] Building QEMU with multiple CPU targets.

[Andreas Färber]

Hi Peter,

Am 08.10.2012 08:39, schrieb Peter Crosthwaite:
> Im currently investigating the possibility of building QEMU with
> multiple CPU architectures active concurrently. That is, I have a
> binary with both an target-arm and target-microblaze and wish to run
> them as a heterogeneous multiprocessor platform.
> 
> Given the recent QOM development in making CPUs just another object,
> shouldn't be possible with a bit of Makefile and configure rework to
> build qemu-system-arm+microblaze and then create machine models
> instantiating both CPU types?
> 
> Are the major complications here from either a Make or QOM perspective?

Neither. The major complication is cpu.h and the per-target functions it
defines/declares.

My CPUState refactoring was a step into that direction, to get a solid
QOM base class rather than macro contents inserted in the middle of the
CPUArchState struct.
But the CPU-as-a-device refactorings and x86 CPU hotplug (APIC among
others) collided with my part 4 series. It also turned out that
refactorings to the TLB code will be necessary to do this cleanly. It
also turned out that my old qom-cpu-4 branch no longer applies, so
instead of rebasing that large branch only to find out I need to rebase
again, I have been cherry-picking or redoing only individual patches so far.

> Has anyone done/tried this before with other architectures and have a
> tree out there somewhere?

See http://wiki.qemu.org/Features/QOM/CPU and feel free to document your
example there.

I had a tree experimentally combining sh4 and arm but that was pre-QOM.
What I tried was creating a new target-rcar with a frontend cpu.h that
delegates to per-CPU code. This was pretty invasive. The proper route to
get there is to move fields into the QOM CPUState struct, so that the
core CPU handling can be shared among softmmus, split off the TLB from
CPUState (as suggested by Blue; requires touching each tcg/*/),
replacing most per-target (inline) functions with hooks on CPUState or
CPU-specific ones (e.g., cpu_mb_init+cpu_arm_init rather than cpu_init).

It's certainly possible to achieve this and I'm working on it, we just
won't be done by tomorrow. ;)

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg