qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v8 4/7] s390x/cpu: Tolerate max_cpus


From: Matthew Rosato
Subject: Re: [Qemu-devel] [PATCH v8 4/7] s390x/cpu: Tolerate max_cpus
Date: Fri, 4 Mar 2016 09:09:17 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 03/04/2016 03:05 AM, David Hildenbrand wrote:
>> Once hotplug is enabled, interrupts may come in for CPUs
>> with an address > smp_cpus.  Allocate for this and allow
>> search routines to look beyond smp_cpus.
>>
>> Signed-off-by: Matthew Rosato <address@hidden>
>> ---
>>  hw/s390x/s390-virtio.c | 13 +++++++------
>>  1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
>> index c501a48..90bc58a 100644
>> --- a/hw/s390x/s390-virtio.c
>> +++ b/hw/s390x/s390-virtio.c
>> @@ -58,15 +58,16 @@
>>  #define S390_TOD_CLOCK_VALUE_MISSING    0x00
>>  #define S390_TOD_CLOCK_VALUE_PRESENT    0x01
>>
>> -static S390CPU **ipi_states;
>> +static S390CPU **cpu_states;
>>
>>  S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
>>  {
>> -    if (cpu_addr >= smp_cpus) {
>> +    if (cpu_addr >= max_cpus) {
>>          return NULL;
>>      }
>>
>> -    return ipi_states[cpu_addr];
>> +    /* Fast lookup via CPU ID */
>> +    return cpu_states[cpu_addr];
>>  }
>>
>>  void s390_init_ipl_dev(const char *kernel_filename,
>> @@ -101,14 +102,14 @@ void s390_init_cpus(MachineState *machine)
>>          machine->cpu_model = "host";
>>      }
>>
>> -    ipi_states = g_malloc(sizeof(S390CPU *) * smp_cpus);
>> +    cpu_states = g_malloc0(sizeof(S390CPU *) * max_cpus);
>>
>> -    for (i = 0; i < smp_cpus; i++) {
>> +    for (i = 0; i < max_cpus; i++) {
>>          S390CPU *cpu;
>>
>>          cpu = cpu_s390x_init(machine->cpu_model);
>>
>> -        ipi_states[i] = cpu;
>> +        cpu_states[i] = cpu;
> 
> This looks wrong (creating all cpus). But the net patch fixes it again.
> 

Ouch.  Definitely wrong, error introduced during patch split.  We
allocate for max_cpus, but should only create smp_cpus cpus during init.

> Can you make this patch a simple rename patch and move the max_cpu stuff into
> the next patch if this makes sense?
> 
> Or simply set the cpu_state for everything above smp_cpus to zero in this 
> patch.

This is done via the gmalloc0.  If I hadn't messed up this loop, the net
result would be the ability to handle > smp_cpus, but nobody will ever
create one (yet).

Matt




reply via email to

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