On Mon, 16 Dec 2013 16:20:04 +0100
Antonios Motakis <a.mota...@virtualopensystems.com> wrote:
> On Sat, Dec 14, 2013 at 4:53 AM, Eric Blake <ebl...@redhat.com> wrote:
>
> > On 12/13/2013 04:14 AM, Antonios Motakis wrote:
> > > This option complements -mem-path. It implies -mem-prealloc. If
> > specified,
> > > the guest RAM is allocated as a shared memory object. If both -mem-path
> > > and -mem-share are provided, the memory is allocated from the HugeTLBFS
> > > supplied path, and then mmapped with MAP_SHARED.
> > >
> > > Signed-off-by: Antonios Motakis <a.mota...@virtualopensystems.com>
> > > Signed-off-by: Nikolay Nikolaev <n.nikol...@virtualopensystems.com>
> > > ---
> >
> > > +++ b/qemu-options.hx
> > > @@ -237,6 +237,15 @@ STEXI
> > > Preallocate memory when using -mem-path.
> > > ETEXI
> > >
> > > +DEF("mem-share", 0, QEMU_OPTION_mem_share,
> >
> > Ouch. Doesn't this mean you are defining a boolean option (absent or
> > present) as opposed to a qemuOpts option? I've already been complaining
> > that other boolean opts are currently undiscoverable to QMP; they also
> > have the drawback of having no way to turn the option back off if an
> > alias turned it on earlier in the command line. Can we use qemuOpts
> > here (so query-command-line-options can see it), and with a boolean
> > on/off argument (so it's not a one-way switch)?
> >
>
> Our implementation of mem-share complements mem-path and mem-prealloc.
> Maybe these options should be combined as one QemuOpts with arguments?
> Is this the memdev that is referred to by Paolo?
memdev is introduced here:
http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg02532.html
as for mem-path & mem-prealloc, I was thinking about adding HugePageMem backend
to handle hugepage specifics. mem-share could be a part of ShareMem backend
or something like this.
>
>
> > --
> > Eric Blake eblake redhat com +1-919-301-3266
> > Libvirt virtualization library http://libvirt.org
> >
> >
