Re: [Qemu-devel] [PATCH for 2.13 1/2] Revert "spapr: Don't allow memory hotplug to memory less nodes"

[Serhii Popovych]

Bharata B Rao wrote:
> On Thu, Apr 05, 2018 at 10:35:22AM -0400, Serhii Popovych wrote:
>> This reverts commit b556854bd8524c26b8be98ab1bfdf0826831e793.
>>
>> Leave change @node type from uint32_t to to int from reverted commit
>> because node < 0 is always false.
>>
>> Signed-off-by: Serhii Popovych <address@hidden>
>> ---
>>  hw/ppc/spapr.c | 22 ----------------------
>>  1 file changed, 22 deletions(-)
>>
>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> index 2c0be8c..3ad4545 100644
>> --- a/hw/ppc/spapr.c
>> +++ b/hw/ppc/spapr.c
>> @@ -3477,28 +3477,6 @@ static void spapr_machine_device_plug(HotplugHandler 
>> *hotplug_dev,
>>              return;
>>          }
>>
>> -        /*
>> -         * Currently PowerPC kernel doesn't allow hot-adding memory to
>> -         * memory-less node, but instead will silently add the memory
>> -         * to the first node that has some memory. This causes two
>> -         * unexpected behaviours for the user.
>> -         *
>> -         * - Memory gets hotplugged to a different node than what the user
>> -         *   specified.
>> -         * - Since pc-dimm subsystem in QEMU still thinks that memory 
>> belongs
>> -         *   to memory-less node, a reboot will set things accordingly
>> -         *   and the previously hotplugged memory now ends in the right 
>> node.
>> -         *   This appears as if some memory moved from one node to another.
>> -         *
>> -         * So until kernel starts supporting memory hotplug to memory-less
>> -         * nodes, just prevent such attempts upfront in QEMU.
>> -         */
>> -        if (nb_numa_nodes && !numa_info[node].node_mem) {
>> -            error_setg(errp, "Can't hotplug memory to memory-less node %d",
>> -                       node);
>> -            return;
>> -        }
>> -
> 
> If you remove this unconditionally, wouldn't it be a problem in case
> of newer QEMU with older guest kernels ?

Yes, that definitely would affect guest kernels without such support. We
probably need to add some capability to test for guest kernel
functionality presence.

> 
> Regards,
> Bharata.
> 
> 


-- 
Thanks,
Serhii

signature.asc
Description: OpenPGP digital signature