qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 2/2] docs: Document vCPU hotplug procedure


From: Kashyap Chamarthy
Subject: Re: [Qemu-devel] [PATCH v2 2/2] docs: Document vCPU hotplug procedure
Date: Thu, 27 Sep 2018 16:37:13 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

On Wed, Sep 26, 2018 at 05:24:27PM +0200, Igor Mammedov wrote:
> On Tue, 25 Sep 2018 18:02:48 +0200
> Kashyap Chamarthy <address@hidden> wrote:

[...]

> > +(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 
> ...

Sure, I can cut it down.  (That specific command-line is what I normally
use when playing with the QEMU Block Layer.)

> 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

I'll probably just mention about PPC and s390.  But adding examples for
them too is a bit redundant.

> In addition one could coldplug cpus the same way as other devices
> using -device CLI option.

Good point, I'll mention it.

> > +(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)

As a user of QMP, I don't find that phrasing clear as well, I'm afraid.
Wonder if there's a way better way to tell what's happening here.
 
[...]

> > +(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.

Noted.

[...]

> > +(5) Optionally, run QMP `query-cpus-fast` for some details about the
> > +    vCPUs::
> > 
> I'd replace it with another query-hotpluggable-cpus call

Will do.

> > +
[...]

> > +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/

Will fix.

Thanks for the review, Igor!

-- 
/kashyap



reply via email to

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