Re: [Qemu-devel] [RFC v2 0/6] QEMU shared-memory backend

[Baptiste Reynal]

On Thu, Apr 7, 2016 at 6:27 PM, Markus Armbruster <address@hidden> wrote:
> Baptiste Reynal <address@hidden> writes:
>
>> On Tue, Mar 22, 2016 at 3:14 PM, Markus Armbruster <address@hidden> wrote:
>>>
>>> Copying Paolo, author of memory-backend-file.
>>>
>>> Baptiste Reynal <address@hidden> writes:
>>>
>>> > A new memory backend, the shared memory backend, based on
>>> > the file memory backend.
>>> >
>>> > This new backend allows a master QEMU instance to share a part of
>>> > his main memory whith a slave QEMU instance. It is then possible to load
>>> > a firmware on this memory and trigger the slave boot using a SDM
>>> > signal.
>>>
>>> Can you explain why that's useful in a bit more detail?
>>>
>>
>> The purpose of such memory backend is to enable the modeling
>> of asymmetric multiprocessing (AMP) configurations. An example is
>> a multi-core ARM CPU working alongside with two Cortex-M
>> micro controllers.
>>
>> On such configurations many CPU (modeled by many QEMU
>> instances) share the same memory bus. This patch series allows multiple
>> QEMU instances to share the same file-backed memory bus.
>
> All right, this is for implementing (heterogenous) multi-core via
> multiple QEMU instances.  The alternative would be making one QEMU
> instance support more different CPUs.  Which one is the more promising
> approach I can't say.

We decided to implement it using multiple QEMU instances in order to
reduce the impact on QEMU code.

>
>>> > Such new backend enables, on a master side, to allocate the whole
>>> > memory as shareable (e.g. /dev/shm, or hugetlbfs).
>>>
>>> memory-backend-file can do that already.  What exactly does
>>> memory-backend-shared add to it?
>>
>> This memory-backend-shared allows multiple QEMU instances to share the
>> same memory backend. A slave instance will have access only to a subset of
>> the whole AMP system memory, by mapping just one part of the file as its
>> memory. This can be considered as an MMU configured by the master processor
>> to restrict slave memory accesses to only a subset of the whole system 
>> memory.
>>
>> For the purpose of AMP modeling, a QEMU instance can be put in waiting mode
>> (by using QEMU migration) until a master QEMU triggers its boot. It allows 
>> the
>> master to fill the slave memory with its firmware before boot, in order to be
>> compliant with the remoteproc framework (power on, load firmware, power off).
>
> If I understand you correctly, you need two things: multiple QEMU
> instances sharing (some) memory, and a signalling mechanism between
> them.
>
> memory-backend-file provides the former, but by itself can't provide the
> latter.
>
> Is this roughly correct?

Exactly. The signaling mechanism is handled by the SDM device,
presented here:
https://www.mail-archive.com/address@hidden/msg361316.html