qemu-devel
[Top][All Lists]
Advanced

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

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


From: Bandan Das
Subject: Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option
Date: Thu, 20 Jun 2013 12:02:07 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

> Il 20/06/2013 15:26, Eduardo Habkost ha scritto:
>> On Thu, Jun 20, 2013 at 11:52:42AM +0200, Paolo Bonzini wrote:
>>> Il 20/06/2013 11:30, Igor Mammedov ha scritto:
>>>>>>>>>> So, basically the format seemed easier to work with if we are 
>>>>>>>>>> thinking 
>>>>>>>>>> of using QemuOpts for -numa. Using -cpu rather than cpus probably
>>>>>>>>>> makes it less ambiguous as well IMO. However, it's probably not a 
>>>>>>>>>> good idea
>>>>>>>>>> if the current syntax is well established ?
>>>>>>
>>>>>> libvirt uses the "cpus" option already, so we have to keep it working.
>>>> Sure, we can leave it as it's now for some time while a new interface is
>>>> introduced/adopted. And than later deprecate "cpus".
>>>
>>> So, you used a new name because the new behavior of "-numa
>>> node,cpus=1-2,cpus=3-4" would be incompatible with the old.
>> 
>> I don't think anybody uses "cpus=1-2,cpus=3-4" today, so I believe we
>> can change its behavior. The problem was to get agreement on the syntax
>> to represent multiple CPU ranges.
>
> Ok.  I think almost everyone agreed on "cpus=1-2,cpus=3-4", which is
> basically what Bandan's patch does minus s/cpu/cpus/.  It matches what
> already happens with other options (SLIRP), so it's hardly surprising.

Good, so should I spin a new version with "cpus" ?

Also note that this patch actually doesn't add any extra code to support 
multiple cpus arguments. It all happens automatically as part of conversion to
QemuOpts. So, if we need to revisit the syntax later, we can always do that.

Bandan
> Let's go on with that.
>
> Paolo
>
>>> Personally I don't think that's a problem, but I remember a long
>>> discussion in the past.  Igor/Eduardo, do you remember the conclusions?
>> 
>> I don't remember seeing the discussion reach any conclusion,
>> unfortunately.
>> 



reply via email to

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