From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoCmO-0006JI-19 for qemu-devel@nongnu.org; Thu, 07 Apr 2016 12:27:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoCmJ-0003MO-3R for qemu-devel@nongnu.org; Thu, 07 Apr 2016 12:27:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoCmI-0003MI-Ry for qemu-devel@nongnu.org; Thu, 07 Apr 2016 12:27:31 -0400 From: Markus Armbruster References: <1458292438-13909-1-git-send-email-b.reynal@virtualopensystems.com> <874mbyppl7.fsf@blackfin.pond.sub.org> Date: Thu, 07 Apr 2016 18:27:28 +0200 In-Reply-To: (Baptiste Reynal's message of "Tue, 22 Mar 2016 15:54:13 +0100") Message-ID: <87inztwfin.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [RFC v2 0/6] QEMU shared-memory backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Baptiste Reynal Cc: Paolo Bonzini , Jani.Kokkonen@huawei.com, VirtualOpenSystems Technical Team , Claudio.Fontana@huawei.com, qemu list Baptiste Reynal writes: > On Tue, Mar 22, 2016 at 3:14 PM, Markus Armbruster wrote: >> >> Copying Paolo, author of memory-backend-file. >> >> Baptiste Reynal 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?