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

[Edgar E. Iglesias]

On Mon, Oct 08, 2012 at 03:53:37PM -0500, Anthony Liguori wrote:
> Peter Maydell <address@hidden> writes:
> 
> > On 8 October 2012 21:23, Anthony Liguori <address@hidden> wrote:
> >> It may be possible to cheat and compile the TCG + CPU code multiple
> >> times as dynamic libraries.  You can then load the libraries with
> >> dlopen() with local symbol resolution.
> >
> > ...and when the common code wants to (say) call cpu_exit() on a
> > particular core, how does it know which DLL's version to call?
> > That said, I have a feeling I've heard about people trying this
> > kind of approach before, so it's probably possible to get something
> > that works on at least one host OS. I think doing it "properly"
> > would be less of a hack, though...
> 
> I think you basically need to treat a "foreign" CPU separately from a
> local CPU.  You would load foreign CPUs as libraries and interact with
> it separately.
> 
> I think the initial focus should be on hacking something to work.  Then
> we can figure out what's the best path to merging.


Hi,

I hacked on a similar shared lib approach a couple of years ago and got
it kind of working. It wasn't exactly the thing beeing discussed here
because in my case the various qemu instances were driven by an external
simulator but anyway. This was before the io-thread was mandatory and
glib was not so integrated. Later when I tried to update, I ran into
lots of thread issues and glib stepping on it's self. I didn't look
to much into it but it seem to get very messy.

I think that Anothonys and Maydells ideas can in some sense be combined.
If people start working on the "long term" approach of fixing things
within QEMU, other people will show up with ideas/patches that "make things"
work. But IMO, we need to start working on the inner issues asap.

Andreas work with cleaning up the CPU interfaces is great. Others
have helped with making the devices much more target independent etc.
All of those steps help. If we could build all the devices into a single
qemu and have just the CPU's in separate libraries, that would be a first
step (maybe that's almost possible now).  Then get rid of the endianness and
pagesize and other target cpu issues.

Heterogeneous cpus is becoming a killer feature in SOC emulation. Or, I'm
probably wrong. It _already_ is a killer feature. You can't model many modern
socs without it, unless you take shortcuts and model remote cpus and their
interfaces as pure hw device models or maybe if you do some kind of
remote/IPC connections.

Cheers