qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [patch 0/2] force -mem-path RAM allocation
Date: Wed, 09 Oct 2013 08:23:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Marcelo Tosatti <address@hidden> 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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]