I've done some investigating into using the device_add hmp/qmp command
to support hot-plugging cpus on S390. The alternative suggestion was to
simply use a new cpu_add hmp/qmp command.
device_add accepts all of the same options as the -device command line
parameter takes. This would imply that to hot-plug cpu's using device
add we would need to allow command line arguments of type "-device cpu".
All of the implications of this are not currently clear to me. How
would this interact with the -smp option, for example, how many cpus are
created in this case:
qemu -smp 2 -device cpu,id=cpu0 -device cpu,id=cpu1, -device
cpu,id=cpu2
Is -smp invalid when cpu devices are specified? We would have to fill
the smp_cpus variable after all (cpu) devices have been parsed.
Since device_add requires a QOM object name (driver parameter) we
seem to have
two choices.
1. device_add cpu
2. device_add s390-cpu
But "cpu" is actually an abstract QOM class and cannot be instantiated
by object_new("cpu") as is done in device_add processing. So we need to
use "s390-cpu". This adds an architecture specific flavor to cpu
hotplug. I would think we'd want to avoid that somehow. perhaps we
simply "translate" that parameter during early device_add processing?
Another issue is that the s390-cpu QOM object class is a child of
"main-system-bus". This bus does not support hotplug:
sysbus->allow_hotplug=0. In order to implement cpu hotplug we would need
to either switch sysbus->allow_hotplug to 1, or the s390-cpu QOM object
class would need to move to a bus that supports hotplug. I'm not sure
what the implications of either choice would be.
I'm interested in thoughts and comments. Thanks!
--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)