On 27/07/2015 15:54, Christian Pinto wrote:
From the user point of view there is usually an operating system
booting on the Master processor (e.g. Linux) at platform startup,
while the other processors are used to offload the Master one from
some computation or to deal with real-time interfaces. It is the
Master OS that triggers the boot of the Slave processors, and
provides them also the binary code to execute (e.g. RTOS, binary
firmware) by placing it into a pre-defined memory area that is
accessible to the Slaves. Usually the memory for the Slaves is
carved out from the Master OS during boot. Once a Slave is booted the
two processors can communicate through queues in shared memory and
inter-processor interrupts (IPIs). In Linux, it is the
remoteproc/rpmsg framework that enables the control (boot/shutdown)
of Slave processors, and also to establish a communication channel
based on virtio queues.
Currently, QEMU is not able to model such an architecture, mainly
because only a single processor can be emulated at one time, and the
OS binary image needs to be placed in memory at model startup.
Hi, you may be interested in the "multi-arch" patches here:
http://thread.gmane.org/gmane.comp.emulators.qemu/351808
These do roughly what you are saying, though in a single QEMU process.