[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2 0/6] QEMU shared-memory backend
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC v2 0/6] QEMU shared-memory backend |
Date: |
Wed, 6 Apr 2016 09:57:57 +0100 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
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?
signature.asc
Description: PGP signature