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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list