On Wed, 6 Apr 2016 09:57:57 +0100 Stefan Hajnoczi <stefa...@gmail.com> 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 <stefa...@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. > > 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
