[Top][All Lists]

[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

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]