[libvirt] [PATCHv3 2/6] qemu: use query-cpus-fast in JSON monitor

[John Ferlan]

On 04/04/2018 10:45 AM, Viktor Mihajlovski wrote:
> Use query-cpus-fast instead of query-cpus if supported by QEMU.
> Based on the QEMU_CAPS_QUERY_CPUS_FAST capability.
> 
> Signed-off-by: Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com>
> ---
>  src/qemu/qemu_domain.c       | 14 +++++++++++---
>  src/qemu/qemu_monitor.c      | 30 ++++++++++++++++++------------
>  src/qemu/qemu_monitor.h      |  7 +++++--
>  src/qemu/qemu_monitor_json.c | 37 +++++++++++++++++++++++++++----------
>  src/qemu/qemu_monitor_json.h |  3 ++-
>  tests/qemumonitorjsontest.c  |  4 ++--
>  6 files changed, 65 insertions(+), 30 deletions(-)
> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 9d1c33b..662937b 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -9006,7 +9006,12 @@ qemuDomainRefreshVcpuInfo(virQEMUDriverPtr driver,
>      if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0)
>          return -1;
>  

Count me as one of those that would prefer to see:

    bool fast;
...
    fast = virQEMUCapsGet(QEMU_DOMAIN_PRIVATE(vm)->qemuCaps,
                          QEMU_CAPS_QUERY_CPUS_FAST);
...

> -    rc = qemuMonitorGetCPUInfo(qemuDomainGetMonitor(vm), &info, maxvcpus, hotplug);
> +    rc = qemuMonitorGetCPUInfo(qemuDomainGetMonitor(vm),
> +                               &info,
> +                               maxvcpus,
> +                               hotplug,
> +                               virQEMUCapsGet(QEMU_DOMAIN_PRIVATE(vm)->qemuCaps,
> +                                              QEMU_CAPS_QUERY_CPUS_FAST));

   rc = qemuMonitorGetCPUInfo(qemuDomainGetMonitor(vm), &info, maxvcpus,
                              hotplug, fast);

>  
>      if (qemuDomainObjExitMonitor(driver, vm) < 0)
>          goto cleanup;
> @@ -9025,7 +9030,7 @@ qemuDomainRefreshVcpuInfo(virQEMUDriverPtr driver,
>           * thread, but it runs every vCPU in that same thread. So it
>           * is impossible to setup different affinity per thread.
>           *
> -         * What's more the 'query-cpus' command returns bizarre
> +         * What's more the 'query-cpus[-fast]' command returns bizarre
>           * data for the threads. It gives the TCG thread for the
>           * vCPU 0, but for vCPUs 1-> N, it actually replies with
>           * the main process thread ID.
> @@ -9126,7 +9131,10 @@ qemuDomainRefreshVcpuHalted(virQEMUDriverPtr driver,
>      if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0)
>          return -1;
>  
> -    haltedmap = qemuMonitorGetCpuHalted(qemuDomainGetMonitor(vm), maxvcpus);


> +    haltedmap = qemuMonitorGetCpuHalted(qemuDomainGetMonitor(vm),
> +                                        maxvcpus,
> +                                        virQEMUCapsGet(QEMU_DOMAIN_PRIVATE(vm)->qemuCaps,
> +                                                       QEMU_CAPS_QUERY_CPUS_FAST));

Likewise,

 bool fast;
...

 fast = virQEMUCapsGet(QEMU_DOMAIN_PRIVATE(vm)->qemuCaps,
                       QEMU_CAPS_QUERY_CPUS_FAST);
 haltedmap = qemuMonitorGetCpuHalted(qemuDomainGetMonitor(vm), maxvcpus,
                                     fast);

>  
>      if (qemuDomainObjExitMonitor(driver, vm) < 0 || !haltedmap)
>          goto cleanup;

[...]

John

If you're OK with this I can make the alterations...  What you have
works - it's just one of those preferential things related to seeing
and/or relying on function calls within function calls.