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

[Igor Mammedov]

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