Hi,
Am 03.05.2013 15:50, schrieb Jason J. Herne:
> 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.
A cpu-add QMP command has been merged by now. Using it with
qemu-system-s390x machines will return a QMP error at the moment.
> 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".
In theory we do, ever since making the CPU a device, it just didn't
fully work yet. For all QOM'ified CPUs (i.e., not x86) it should work
crash-free now, but it's untested whether a particular machine copes
with it or not.
> 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
Four, if the correct driver is supplied (error for the above).
The -smp option indicates how many CPUs the *machine* instantiates.
In addition you are trying to create two further devices, just like
other machines create a PCI host bridge and a user might try to add
another one.
> Is -smp invalid when cpu devices are specified? We would have to fill
> the smp_cpus variable after all (cpu) devices have been parsed.
Would we? If so, doing some check of -smp maxcpus and/or updating
whatever variable in CPU's realizefn feels more natural to me than some
post-whatever hook.
> 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?
You are saying that based on the current s390 code. Actually it was
discussed that s390-cpu should be abstract as well and the type should
indicate the actual model - host-s390-cpu, z9-s390-cpu, etc. There were
two KVM calls that covered future structure of CPU modelling (socket ->
core -> thread) and roadmap towards vCPU hotplug - see the minutes on
the list.
The current approach of cpu-add for 1.5 was chosen because the
refactoring of CPUArchState is rather cumbersome and taking too long.
> Another issue is that the s390-cpu QOM object class is a child of
> "main-system-bus". [...]
That's not true, it is not on any bus at all - I have attempted to fix
device_add for this use case and Igor has just sent a patch for unplug.
For x86 we have chosen to introduce the ICC bus to handle hot-adding
APIC devices (which were on SysBus before) alongside the CPU. With
proper CPU modelling that would not be necessary, but for now it has the
advantage of giving us a canonical QOM path to the CPUs for free.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
