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

[Anthony Liguori]

Markus Armbruster <armbru at redhat.com> writes:

> Related: overwrite something you got from a config file on the command
> line.
>
> In both your example and mine, we have entirely separate options, and
> they have perfectly ordinary overwrite semantics: each option overwrites
> the given keys with the given values.  The last key=value wins.
>
> This usage makes sense, and we obviously want to preserve it.
>
> Paolo's example is different only in that it's a silly.  Preserving
> compatibility may mean that once we accepted silly usage, we can't ever
> reject it.  Debatable.  Personally, I disagree: I think we could outlaw
> repeating keys within the same option argument / configuration file
> section just fine.
>
> Finally, I don't think that we must have fancy-pants syntax to remind
> users that they're configuring a list.  What's the chance of confusion
> there?  What user would expect num_queues=1,num_queues=2 to make
> num_queues magically become a list?

My fundamental problem here is that we have the same syntax with
different meanings depending on the context.

Going back to our original example:

    qemu -numa node,nodeid=2,cpus=4

This is certainly ambiguous.  Does this mean that you have a single cpu
for the node (VCPU 4) or does it mean the node have 4 cpus (presumably
ranged 0-3).

Given that ambiguity the following:

    qemu -numa node,nodeid=2,cpus=4,cpus=8

Does help the situation.  A reasonable person could assume that cpus=8
overrides the previous cpus=4 (as it does elsewhere in QEMU) and
therefore assume they were creating a node with 8 CPUS (0-7) instead of
two cpus.  However:

    qemu -numa node,nodeid=2,cpus=4:8

Is much less ambiguous.  Granted, it's not immediately obvious whether
this is a range specification or a disjoint specification but it's more
clear than the previous syntax.

Regards,

Anthony Liguori