[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: |
Christian Borntraeger |
Subject: |
Re: [Qemu-devel] [PATCH 0/4] s390: Allow hotplug of s390 CPUs |
Date: |
Mon, 9 Nov 2015 21:04:27 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
Am 09.11.2015 um 16:56 schrieb Andreas Färber:
> 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?
>
> No, I mean as I've always said: cpu-add was a short-term hack to make
> CPU hotplug work on x86. libvirt certainly needs to be fixed if it
> assumes this to work for s390.
>
> If device_add works, we don't need cpu-add. If device_add does not work,
> we need to know which patches are missing. device_del is a separate
> beast and there were also patches around that seemed incomplete
> according to Eduardo.
Given that s390 plugs CPUs without sockets, it would boild down to an opaque
cpu, so
- Matt will remove the hot_add function from patch 4 (which makes it smaller)
- we provide a followup patch for libvirt
- Matt fixes the maxcpus overrun
- In addition we would need something like
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
index 266575c..cfcff52 100644
--- a/target-s390x/cpu.c
+++ b/target-s390x/cpu.c
@@ -377,7 +377,7 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data)
scc->parent_realize = dc->realize;
dc->realize = s390_cpu_realizefn;
-
+ dc->cannot_instantiate_with_device_add_yet = false;
scc->parent_reset = cc->reset;
#if !defined(CONFIG_USER_ONLY)
scc->load_normal = s390_cpu_load_normal
With that device_add s390-cpu seems to work.
> Bharata did implement device_add for pseries, I thought.
Seems that the patches did not make it into upstream yet.
Bharata, is cpu hotplug on pseries still missing?
Christian
- [Qemu-devel] [PATCH 1/4] s390x/cpu: Cleanup init in preparation for hotplug, (continued)
- [Qemu-devel] [PATCH 1/4] s390x/cpu: Cleanup init in preparation for hotplug, Matthew Rosato, 2015/11/09
- [Qemu-devel] [PATCH 2/4] s390x/cpu: Set initial CPU state in common routine, Matthew Rosato, 2015/11/09
- [Qemu-devel] [PATCH 3/4] s390x/cpu: Add function to set CPU state, Matthew Rosato, 2015/11/09
- [Qemu-devel] [PATCH 4/4] s390x/cpu: Allow hotplug of CPUs, Matthew Rosato, 2015/11/09
- Re: [Qemu-devel] [PATCH 0/4] s390: Allow hotplug of s390 CPUs, Andreas Färber, 2015/11/09