Baptiste Reynal <b.rey...@virtualopensystems.com> writes: > On Tue, Mar 22, 2016 at 3:14 PM, Markus Armbruster <arm...@redhat.com> wrote: >> >> Copying Paolo, author of memory-backend-file. >> >> Baptiste Reynal <b.rey...@virtualopensystems.com> 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?
