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

From: Baptiste Reynal <b.reynal@virtualopensystems.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Jani.Kokkonen@huawei.com,
	VirtualOpenSystems Technical Team <tech@virtualopensystems.com>,
	Claudio.Fontana@huawei.com, qemu list <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC v2 0/6] QEMU shared-memory backend
Date: Tue, 5 Apr 2016 14:00:40 +0200	[thread overview]
Message-ID: <CAN9JPjFesicxAgPRRvUXbQH_=9CM6X4gcF79FSTOBP++5He_RA@mail.gmail.com> (raw)
In-Reply-To: <20160331091452.GF32185@stefanha-x1.localdomain>

On Thu, Mar 31, 2016 at 11:14 AM, Stefan Hajnoczi <stefanha@gmail.com> 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.