On 04/23/2013 09:52 AM, Daniel P. Berrange wrote:
> Any other design or naming suggestions are welcome.
Since 'cpu_id' in this refers to the guest OS' notion of CPUs,
do we need some way to expose what the guest OS considers the
CPU IDs to be.
Qemu is still working on that point. For 1.5, the recommendation is to
use sequential numbering and only hotplug the next available number
(since hotunplug won't make 1.5). For 1.6, the numbers might not be
contiguous, based on ACPI constraints, so they are planning on designing
something that would report the available ids that can be used in the
first place, at which point libvirt would then have to worry about
tracking arbitrary in-use ids rather than sequential.
https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg04625.html
Personally I like the simpler first API, since it has easy to
understand error behaviour.
What is the data format QEMU agent requires for toggling CPUs ?
Does it allow multiple CPUs to be changed at once ?
The current agent command allows multiple cpus to be toggled in one
command (but we don't necessarily need to expose that complexity);
whereas the monitor command for cpu-add is only one cpu per command.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org