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

[Markus Armbruster]

Baptiste Reynal <address@hidden> writes:

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

Understood.

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

Got it, thanks.

I think your commit message needs to explain why
memory-backend-file,share doesn't suffice for your use case (assuming it
doesn't).  You elaborated on your use case in reply to my question
(quoted above), but 1. you didn't quite answer my question why
memory-backend-file won't do, and 2. it should really be in git.