| Message ID | 20170904154316.4148-17-david@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | s390x cleanups and CPU hotplug via device_add | expand |
On 09/04/2017 11:43 AM, David Hildenbrand wrote: > E.g. the following now works: > device_add host-s390-cpu,id=cpu1,core-id=1 > > The system will perform the same checks as when using cpu_add: > - If the core_id is already in use > - If the next sequential core_id isn't used > - If core-id >= max_cpu is specified > > In addition, mixed CPU models are checked. E.g. if starting with > -cpu host and trying to hotplug "qemu-s390-cpu": > "Mixed CPU models are not supported on s390x." > > Signed-off-by: David Hildenbrand <david@redhat.com> As easy as flipping a switch, right? Tested the new device_add path, the old cpu-add path and mixed cases where I alternated adding cpus via both methods -- looking good. Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> > --- > target/s390x/cpu.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c > index 105ff13034..be20c2fb0f 100644 > --- a/target/s390x/cpu.c > +++ b/target/s390x/cpu.c > @@ -466,6 +466,7 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data) > scc->parent_realize = dc->realize; > dc->realize = s390_cpu_realizefn; > dc->props = s390x_cpu_properties; > + dc->user_creatable = true; > > scc->parent_reset = cc->reset; > #if !defined(CONFIG_USER_ONLY) >
On 07.09.2017 05:16, Matthew Rosato wrote: > On 09/04/2017 11:43 AM, David Hildenbrand wrote: >> E.g. the following now works: >> device_add host-s390-cpu,id=cpu1,core-id=1 >> >> The system will perform the same checks as when using cpu_add: >> - If the core_id is already in use >> - If the next sequential core_id isn't used >> - If core-id >= max_cpu is specified >> >> In addition, mixed CPU models are checked. E.g. if starting with >> -cpu host and trying to hotplug "qemu-s390-cpu": >> "Mixed CPU models are not supported on s390x." >> >> Signed-off-by: David Hildenbrand <david@redhat.com> > > As easy as flipping a switch, right? Yes, luckily all that hotplug handling already was in place, just core-id vs. id had to be fixed. > > Tested the new device_add path, the old cpu-add path and mixed cases > where I alternated adding cpus via both methods -- looking good. > > Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> > Thanks!
diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c index 105ff13034..be20c2fb0f 100644 --- a/target/s390x/cpu.c +++ b/target/s390x/cpu.c @@ -466,6 +466,7 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data) scc->parent_realize = dc->realize; dc->realize = s390_cpu_realizefn; dc->props = s390x_cpu_properties; + dc->user_creatable = true; scc->parent_reset = cc->reset; #if !defined(CONFIG_USER_ONLY)
E.g. the following now works: device_add host-s390-cpu,id=cpu1,core-id=1 The system will perform the same checks as when using cpu_add: - If the core_id is already in use - If the next sequential core_id isn't used - If core-id >= max_cpu is specified In addition, mixed CPU models are checked. E.g. if starting with -cpu host and trying to hotplug "qemu-s390-cpu": "Mixed CPU models are not supported on s390x." Signed-off-by: David Hildenbrand <david@redhat.com> --- target/s390x/cpu.c | 1 + 1 file changed, 1 insertion(+)