Re: [Qemu-devel] [RFC] Towards an Heterogeneous QEMU

[Christian Pinto <c.pinto@virtualopensystems.com>]

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