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

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. [...]