Hello Paolo,
On 31/07/2015 15:10, Paolo Bonzini wrote:
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.
Thanks for pointing this out. In fact the final goal is the same: model
a system embedding a heterogeneous set of processors.
The approach presented in this RFC is to provide the building blocks,
and extensions, to experiment with heterogeneous
systems functional modeling by exploiting the current "architecture" of
QEMU in the less invasive possible way.
In addition, once the multi-arch work will be finished, there will still
be the need to implement some sort of inter-processor
signaling/communication and part of our work (i.e. the Interrupt
Distribution Module) might be used for such scope.
Thanks,
Christian
Paolo
