Re: [Qemu-devel] [patch 0/2] force -mem-path RAM allocation

[Marcelo Tosatti <mtosatti@redhat.com>]

On Wed, Oct 09, 2013 at 08:23:26AM +0200, Markus Armbruster wrote:
> Marcelo Tosatti <mtosatti@redhat.com> writes:
> 
> > On Tue, Oct 08, 2013 at 10:02:26AM +0200, Paolo Bonzini wrote:
> >> Il 08/10/2013 09:32, Markus Armbruster ha scritto:
> >> > We have
> >> > 
> >> >     -mem-path FILE  provide backing storage for guest RAM
> >> >     -mem-prealloc   preallocate guest memory (use with -mem-path)
> >> > 
> >> > PATCH 2/2 adds
> >> > 
> >> >     -mem-path-force fail if unable to allocate RAM as specified by
> >> > -mem-path
> >> > 
> >> > Looks like it's time to consolidate the options related to guest memory
> >> > into a single, QemuOpts-style -memory NAME=VALUE,...  What do you guys
> >> > think?
> >> 
> >> Yes, we can use "-numa memory" (or "-numa mem") that Wanlong Gao is
> >> adding.  We can add path=, preallocate= and force= options there.
> >> 
> >> Paolo
> >
> > It would be important for the new option to be backportable 
> > independently. Therefore mixing it with -numa is not an option.
> >
> > Also due to backportability supporting a new style of command line
> > for -mem-path is problematic (management must be changed accordingly).
> 
> We've converted -FOO ARG options to QemuOpts-style -FOO
> NAME=VALUE,... before.  You can use QemuOptsList member implied_opt_name
> to get bare ARG accepted.  Works except for ARGs containing '=' or ','.
> 
> Management still has to detect whether -FOO is old or new.  QMP command
> query-command-line-options should do.
> 
> > Can the new option format for memory be created incrementally on 
> > top of -mem-path-force? (agree its a good thing, it avoids proliferation
> > of new options).
> 
> If you do it on top, it won't avoid proliferation, or am I missing
> something?

Right. But in fact, the new option is not necessary. 

So please consider only patch 2 for inclusion.