[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jason J. Herne
Subject: Re: [Qemu-devel] [RFC/PATCH 0/1] cpu hotplug for s390
Date: Fri, 03 May 2013 09:50:50 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

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
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 (address@hidden)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]