On Wed, Oct 09, 2013 at 08:23:26AM +0200, Markus Armbruster wrote: > Marcelo Tosatti <mtosa...@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.