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

[Baptiste Reynal]

On Wed, Apr 6, 2016 at 3:47 PM, Igor Mammedov <address@hidden> wrote:
> On Wed, 6 Apr 2016 09:57:57 +0100
> Stefan Hajnoczi <address@hidden> wrote:
>
>> On Tue, Apr 05, 2016 at 02:00:40PM +0200, Baptiste Reynal wrote:
>> > On Thu, Mar 31, 2016 at 11:14 AM, Stefan Hajnoczi <address@hidden> wrote:
>> > >
>> > > On Fri, Mar 18, 2016 at 10:13:52AM +0100, Baptiste Reynal wrote:
>> > > > 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.
>> > > >
>> > > > Such new backend enables, on a master side, to allocate the whole
>> > > > memory as shareable (e.g. /dev/shm, or hugetlbfs).
>> > >
>> > > How is this different from qemu -mem-path which can be used for
>> > > hugetlbfs?
>> >
>> > A new mechanism is integrated here. This shared memory allows the
>> > slave to map dynamically only a subregion of the master memory, when
>> > with mempath the entire memory is shared.
>> > A use-case can be the use of remoteproc framework on Linux. Remoteproc
>> > carveout a memory region and load the slave firmware to this region,
>> > then send the size and offset to the slave before boot. The slave
>> > memory region is unknown before master execution, it cannot be set in
>> > QEMU command line.
>>
>> Igor: Do you know what level of control QEMU already has for individual
>> DIMMs backed by hugetlbfs?  Is it possible to have just a specific
>> physical memory range on hugetlbfs by defining individual DIMMs on the
>> command-line?
> it should be possible by using memory-backend-file object with "mem-path"
> property pointing to hugetlbfs and property "share" should help to make
> it shared.
>
> Also one could use backend for initial memory as well via
>  -numa xxx,memdev=foo
> option

Thanks for the help.
>From my understanding the solution will be each slave backed by a
different hugetlbfs file shared with the master. This solution seems
acceptable. The dynamic aspect is lost but it is not mandatory. In
some AMP implementation (i.e OMAP remoteproc) the entire memory is
shared and the memory protection is assured by an IOMMU, the lack of
IOMMU in this project forces us to have some static configuration at
some point.
The next version will then focus on the incoming state with a boot signal.