[libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option

Eduardo Habkost ehabkost at redhat.com
Thu Feb 21 20:57:46 UTC 2013


On Thu, Feb 21, 2013 at 09:23:22PM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost at redhat.com> writes:
> 
> > This allows "," to be used a separator between each CPU range.  Note
> > that commas inside key=value command-line options have to be escaped
> > using ",,", so the command-line will look like:
> >
> >   -numa node,cpus=A,,B,,C,,D
> 
> This is really, really ugly, and an embarrassment to document.  Which
> you didn't ;)

I was trying to have an intermediate solution using the current -numa
parser. I have patches in my queue that will change the code to properly
use QemuOpts later.

It would be interesting to support the "A,B,C,D" format in config files,
though, as it is simple and straighforward when no escaping is required.


> 
> What about
> 
>     -numa node,cpus=A,cpus=B,cpus=C,cpus=D

Looks better for the command-line usage, at least. I will give it a try.

> 
> Yes, QemuOpts lets you do that. Getting all the values isn't as easy as
> it could be (unless you use Laszlo's opt-visitor), but that could be
> improved.

Guess what: -numa doesn't even use QemuOpts, and I am not sure the
current format of -numa will allow QemuOpts to be used easily. I expect
the proper solution using QemuOpts to involve having a
standards-compliant "numa-node" config section instead of this weird
"-numa <type>,..." format where the only valid <type> that ever existed
was "node".

But I believe it will be feasible to allow "cpus=A,cpus=B" using the
current parser, before we convert to a proper QemuOpts-based
implementaiton.

> 
> > Note that the following format, currently used by libvirt:
> >
> >   -numa nodes,cpus=A,B,C,D
> >
> > will _not_ work yet, as "," is the option separator for the command-line
> > option parser, and it will require changing the -numa option parsing
> > code to handle "cpus" as a special case.
> 
> No way.

Agreed.  :-)

The bad news is that libvirt uses this format since forever, this format
never worked, and nobody ever noticed that this was broken.

-- 
Eduardo




More information about the libvir-list mailing list