qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/4] s390: Allow hotplug of s390 CPUs


From: Matthew Rosato
Subject: Re: [Qemu-devel] [PATCH 0/4] s390: Allow hotplug of s390 CPUs
Date: Mon, 9 Nov 2015 11:07:03 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 11/09/2015 10:55 AM, Christian Borntraeger wrote:
> Am 09.11.2015 um 16:37 schrieb Christian Borntraeger:
>> Am 09.11.2015 um 16:35 schrieb Christian Borntraeger:
>>> Am 09.11.2015 um 16:28 schrieb Andreas Färber:
>>>> Hi,
>>>>
>>>> Am 09.11.2015 um 16:17 schrieb Matthew Rosato:
>>>>> To subsequently hotplug a CPU:
>>>>>
>>>>> Issue 'cpu-add <id>' from qemu monitor, or use virsh setvcpus --count <n> 
>>>>> <domain>, where <n> is the total number of desired guest CPUs.
>>>>
>>>> What exactly is still missing for you to use the standard device_add?
>>>>
>>>> Last time I checked (a while ago...) some patches were stuck on the x86
>>>> side, and I don't recall hearing any feedback from the s390x side in my
>>>> KVM Forum CPU hotplug session.
>>>
>>> libvirt uses "cpu-add" unconditionally for hotplugging, so we certainly 
>>> want to support that. 
>>
>> Sorry, hit send too early. I assume you want us to support device_add of
>> a CPU in addition to that. Correct? 
> 
> I just did a quick test with Matts patch.
> 
> after applying
> 
> diff --git a/qom/cpu.c b/qom/cpu.c
> index fb80d13..8152744 100644
> --- a/qom/cpu.c
> +++ b/qom/cpu.c
> @@ -360,7 +360,7 @@ static void cpu_class_init(ObjectClass *klass, void *data)
>       * Reason: CPUs still need special care by board code: wiring up
>       * IRQs, adding reset handlers, halting non-first CPUs, ...
>       */
> -    dc->cannot_instantiate_with_device_add_yet = true;
> +//    dc->cannot_instantiate_with_device_add_yet = true;
>  }
> 
>  static const TypeInfo cpu_type_info = {
> 
> I was able to use
> 
> device_add s390-cpu
> 
> but no comprehensive testing was done.
> I was even able to add more cpus than maxcpus, but the guest could not
> make use of it. Fix is probably easy. But in general it looks like
> that we _could_ enable device_add for CPUs as soon as others are ready
> as well.
> Matt, do you agree?
> 

Yes, I'm seeing the same behavior.  We're just not checking max_cpus in
device init, but the "extra" CPUs cannot be brought online.

Matt




reply via email to

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