[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2 0/6] QEMU shared-memory backend
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [RFC v2 0/6] QEMU shared-memory backend |
Date: |
Thu, 07 Apr 2016 18:27:28 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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?