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

[John Ferlan]

On 03/26/2018 07:28 AM, Viktor Mihajlovski wrote:
> On 26.03.2018 10:12, Viktor Mihajlovski wrote:
>> On 23.03.2018 17:05, John Ferlan wrote:
>> [...]
>>>> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
>>>> index 8b4efc8..4079fb3 100644
>>>> --- a/src/qemu/qemu_domain.c
>>>> +++ b/src/qemu/qemu_domain.c
>>>> @@ -8683,7 +8683,12 @@ qemuDomainRefreshVcpuInfo(virQEMUDriverPtr driver,
>>>>      if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0)
>>>>          return -1;
>>>>  
>>>> -    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));
>>>
>>> Perhaps we should create a qemuMonitorGetCPUInfoFast API since we should
>>> also be able to return the @props {core-id, thread-id, socket-id} and
>>> report them. I'm not steadfast on this suggestion - maybe Peter has a
>>> stronger opinion one way or the other. Still it allows future
>>> adjustments and additions to -fast to be more easily "handled".
>>>
>>> It would seem those values could be useful although I do see there could
>>> be some "impact" with how hotplug works and the default setting to -1 of
>>> the values by qemuMonitorCPUInfoClear.
>> Actually, query-cpus[-fast] is not reporting the topology (socket, core,
>> thread). The reported thread id is referring to the QEMU CPU thread.
> Well, I have to take that back as I ignored that QEMU is providing the
> props since 2.10 with query-cpus (and now with query-cpus-fast). If we
> decide to parse the props, we could do it with the pre-existing
> qemuMonitorGetCPUInfo function, but I would prefer this to be done in
> separate patch.
> [...]
> 

I didn't even look at the query-cpus and @props - I was just considering
the -fast code.  And yes, looking at @props for query-cpus would have to
be a separate patch with it's own capability - if of course it was even
deemed worthwhile to do...

John