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: Wanlong Gao
Subject: Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option
Date: Fri, 21 Jun 2013 14:53:15 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

On 06/21/2013 12:02 AM, Bandan Das wrote:
> 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" ?

I already merged your patch to my patch set "Add support for binding guest numa 
nodes to host numa nodes"
since I should base on that.

Thanks,
Wanlong Gao

> 
> 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]