On Thu, Apr 7, 2016 at 6:27 PM, Markus Armbruster <arm...@redhat.com> wrote: > 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.
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/qemu-devel@nongnu.org/msg361316.html
