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

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> Paolo Bonzini <address@hidden> writes:
>
>> Il 27/02/2013 16:42, Anthony Liguori ha scritto:
>>> There's such thing as list support in QemuOpts.  The only way
>>> QemuOptsVisitor was able to implement it was to expose QemuOpts publicly
>>> via options_int.h and rely on a implementation detail.
>>> 
>>> There are fixed types supported by QemuOpts.  It just so happens that
>>> whenever qemu_opt_set() is called, instead of replacing the last
>>> instance, the value is either prepended or appended in order to
>>> implement a replace or set-if-unset behavior.
>>
>> Fair enough.  Nobody said the implementation is pretty.
>>
>>> If we want to have list syntax, we need to introduce first class support
>>> for it.  Here's a simple example of how to do this.
>>
>> If it is meant as a prototype only, and the final command-line syntax
>> would be with repeated keys, that's okay.  I think that Eduardo/Markus/I
>> are focusing on the user interface, you're focusing in the
>> implementation.
>
> No, I'm primarily motivated by the UI and am assuming that ya'll are
> arguing based on the implementation today.

Your assumption is incorrect :)

>                                             Repeating keys is quite
> mad.  Here are some examples:
>
> qemu -numa node=1,node=2,cpus=2,cpus=3
>
> What would a user expect that that would mean.

I figure you mean

    -numa node,nodeid=1,nodeid=2,cpus=2,cpus=3

Parameter nodeid is int-valued, therefore repeating it is either an
error, or the last one wins.  Matter of taste.  Currently, we do the
latter.

Parameter cpus is list-valued, therefore the values accumulate.  We
already do that.

Taken together, this configures node 1 to use cpus 2 and 3.

>                                                 What about:
>
> [numa]
> node=1
> cpus=2
> cpus=3
>
> qemu -readconfig numa.cfg -numa node=1,cpus=1

I figure you mean

    [numa]
    nodeid=1
    cpus=2
    cpus=3

    qemu -readconfig numa.cfg -numa node,nodeid=1,cpus=1

The config file configures node 1 to use cpus 2 and 3.

The command line configures node 1 to use cpus 1.

QemuOpts can optionally be made to merge options with the same ID.  We
use that in cases like -machine, where multiple options make no sense,
but merging them does.

Merging options doesn't make sense for -numa.  Therefore, configuration
file and command line are *not* merged.  In particular, the two cpus
lists are not merged.

So, what we have is two conflicting bits of configuration for the same
thing.  That's not a new problem, we got that everywhere.  Either treat
as error, or let the last one win.  Matter of taste.  Currently, we do
the latter.

> I'm pretty sure you won't be able to say without looking at the source
> code.

I hereby certify that I did not look at the source code, only at help
output.  So there.

> Now what about ranges?  I'm pretty sure that what a user really wants to
> say is:
>
> qemu -numa node=1,cpus=0-3:8-11
>
> This is easy to do with the patch I sent.  We can add range support
> integer lists by just adding a check for '-' before doing dispatch.
> That's a heck of a lot nicer than:
>
> qemu -numa
> node=1,cpus=0,cpus=1,cpus=2,cpus=3,cpus=8,cpus=9,cpus=10,cpus=11

Let me pick up the baby you just threw out with the bathwater for you:

    qemu -numa node,nodeid=1,cpus=0-3,cpus=8-11

> With respect to escaping, for string lists (the only place where this
> point is even relevant), we can simply support escaping.  But I'd like
> to hear a use-case for a string list first.

There is no need for the syntactic warts you so cavalierly propose.
Whenever you do key=X:Y, I can do key=X,key=Y.  Whatever semantics you
propose for the former, I'll propose for the latter.