On Tue, 25 Sep 2018 18:02:48 +0200 Kashyap Chamarthy <kcham...@redhat.com> wrote:
> Signed-off-by: Kashyap Chamarthy <kcham...@redhat.com> > --- > docs/cpu-hotplug.rst | 140 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 140 insertions(+) > create mode 100644 docs/cpu-hotplug.rst > > diff --git a/docs/cpu-hotplug.rst b/docs/cpu-hotplug.rst > new file mode 100644 > index 0000000000..8f9e63a9f7 > --- /dev/null > +++ b/docs/cpu-hotplug.rst > @@ -0,0 +1,140 @@ > +=================== > +Virtual CPU hotplug > +=================== > + > +A complete example of vCPU hotplug (and hot-unplug) using QMP > +``device_add`` and ``device_del``. > + > +vCPU hotplug > +------------ > + > +(1) Launch QEMU as follows (note that the "maxcpus" is mandatory to > + allow vCPU hotplug):: > + > + $ qemu-system-x86_64 -display none -no-user-config -m 2048 \ > + -nodefaults -monitor stdio -machine pc,accel=kvm,usb=off \ > + -smp 1,maxcpus=2 -cpu IvyBridge-IBRS \ > + -blockdev > node-name=node-Base,driver=qcow2,file.driver=file,file.filename=./base.qcow2 \ > + -device virtio-blk,drive=node-Base,id=virtio0 -qmp > unix:/tmp/qmp-sock,server,nowait all options beside of -smp and -qmp are not relevant here and mostly masking parts that matter, I'd simplify it as much as possible: qemu-system-x86_64 -smp 1,maxcpus=2 -qmp unix:/tmp/qmp-sock,server,nowait ... Also example only covers x86 target, but there are ppc target with spapr machine (add/del) and s390 target (add only). probably should be mentioned here as well In addition one could coldplug cpus the same way as other devices using -device CLI option. > +(2) Run 'qmp-shell' (located in the source tree) to connect to the > + just-launched QEMU:: > + > + $> ./qmp/qmp-shell -p -v /tmp/qmp-sock > + [...] > + (QEMU) > + > +(3) Check which socket is free to allow hotplugging a CPU:: may be: which cpus are possible to plug (an entry with qom-path property describes an existing cpu) > + > + (QEMU) query-hotpluggable-cpus > + { > + "execute": "query-hotpluggable-cpus", > + "arguments": {} > + } > + { > + "return": [ > + { > + "type": "IvyBridge-IBRS-x86_64-cpu", > + "vcpus-count": 1, > + "props": { > + "socket-id": 1, > + "core-id": 0, > + "thread-id": 0 > + } > + }, > + { > + "qom-path": "/machine/unattached/device[0]", > + "type": "IvyBridge-IBRS-x86_64-cpu", > + "vcpus-count": 1, > + "props": { > + "socket-id": 0, > + "core-id": 0, > + "thread-id": 0 > + } > + } > + ] > + } > + (QEMU) > + > +(4) We can see that socket 1 is free, so use `device_add` to hotplug ... and 'arguments' provide a list of property/value pairs to create corresponding cpu. > + "IvyBridge-IBRS-x86_64-cpu":: > + > + (QEMU) device_add id=cpu-2 driver=IvyBridge-IBRS-x86_64-cpu > socket-id=1 core-id=0 thread-id=0 > + { > + "execute": "device_add", > + "arguments": { > + "socket-id": 1, > + "driver": "IvyBridge-IBRS-x86_64-cpu", > + "id": "cpu-2", > + "core-id": 0, > + "thread-id": 0 > + } > + } > + { > + "return": {} > + } > + (QEMU) > + > +(5) Optionally, run QMP `query-cpus-fast` for some details about the > + vCPUs:: I'd replace it with another query-hotpluggable-cpus call > + > + (QEMU) query-cpus-fast > + { > + "execute": "query-cpus-fast", > + "arguments": {} > + } > + { > + "return": [ > + { > + "qom-path": "/machine/unattached/device[0]", > + "target": "x86_64", > + "thread-id": 11534, > + "cpu-index": 0, > + "props": { > + "socket-id": 0, > + "core-id": 0, > + "thread-id": 0 > + }, > + "arch": "x86" > + }, > + { > + "qom-path": "/machine/peripheral/cpu-2", > + "target": "x86_64", > + "thread-id": 12106, > + "cpu-index": 1, > + "props": { > + "socket-id": 1, > + "core-id": 0, > + "thread-id": 0 > + }, > + "arch": "x86" > + } > + ] > + } > + (QEMU) > + > + > +vCPU hot-unplug > +--------------- > + > +From the 'qmp-shell', invoke the QMP ``device_del`` command:: > + > + (QEMU) device_del id=cpu-2 > + { > + "execute": "device_del", > + "arguments": { > + "id": "cpu-2" > + } > + } > + { > + "return": {} > + } > + (QEMU) > + > +.. note:: > + vCPU hot-unplug requires guest cooperation; so the ``device_del`` > + command above does not guarantee vCPU removal -- it's a "request to > + unplug". At this point, the guest will get a System Control > + Interupt (SCI) and calls the ACPI handler for the affected vCPU > + device. Then the guest kernel will bring the vCPU offline and tells > + QEMU to unplug it. s/tells/tell/