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?
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
