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

[Markus Armbruster]

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.

>> > 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?