qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 7/7] vl.c: Use MAX_CPUS macro instead of hard


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v3 7/7] vl.c: Use MAX_CPUS macro instead of hardcoded constant
Date: Fri, 14 Mar 2014 20:38:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

On 03/14/14 20:30, Eduardo Habkost wrote:
> On Fri, Mar 14, 2014 at 08:11:50PM +0100, Laszlo Ersek wrote:
>> On 03/14/14 19:52, Eduardo Habkost wrote:
>>> Signed-off-by: Eduardo Habkost <address@hidden>
>>> ---
>>>  vl.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/vl.c b/vl.c
>>> index 64b38a5..62cc734 100644
>>> --- a/vl.c
>>> +++ b/vl.c
>>> @@ -1413,7 +1413,7 @@ static void smp_parse(QemuOpts *opts)
>>>          max_cpus = smp_cpus;
>>>      }
>>>  
>>> -    if (max_cpus > 255) {
>>> +    if (max_cpus > MAX_CPUS) {
>>>          fprintf(stderr, "Unsupported number of maxcpus\n");
>>>          exit(1);
>>>      }
>>>
>>
>> $ git grep -e '255' --and -e cpus
>>
>> hw/s390x/s390-virtio-ccw.c:    .max_cpus = 255,
>> hw/s390x/s390-virtio.c:    .max_cpus = 255,
>> include/hw/i386/pc.h:    .max_cpus = 255
>> vl.c:    if (max_cpus > 255) {
>>
>> I propose to fix those other tree occurrences as well. (I could be
>> easily wrong of course!, I didn't investigate.)
> 
> We first need to find out the reason behind those machine-specific
> limits. Maybe they can be removed (if they are all because of NUMA
> and/or ACPI), or maybe they need to use another macro because there are
> other limits in machine-specific code.

OK. Until then:

Reviewed-by: Laszlo Ersek <address@hidden>




reply via email to

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