[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>
- [Qemu-devel] [PATCH v3 4/7] acpi: Don't use MAX_CPUMASK_BITS for APIC ID bitmap, (continued)