Re: [Qemu-devel] [RFC/PATCH 0/1] cpu hotplug for s390

["Jason J. Herne" <jjherne@linux.vnet.ibm.com>]

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 (jjherne@linux.vnet.ibm.com)