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

["Andreas Färber" <afaerber@suse.de>]

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