Re: [libvirt] [RFC] kvm: x86: export vCPU halted state to sysfs

On 02.02.2018 16:22, Luiz Capitulino wrote: > On Fri, 2 Feb 2018 16:08:25 +0100 > Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com&gt; wrote: > >>>> A disabled guest CPU is represented as halted in the QEMU object model >>>> and can therefore be identified by the QMP query-cpus command. >>>> >>>> The initial patch proposal to expose this via virsh vcpuinfo was not >>>> considered to be desirable because there was a concern that legacy >>>> management software might be confused seeing halted vcpus. Therefore the >>>> state information was added to the cpu domain statistics. >>>> >>>> One issue we're facing is that the semantics of "halted" are different >>>> between s390 and at least x86. The question might be whether they are >>>> different enough to grant a specific "disabled" indicator. >>> >>> From your description, it looks like they are completely >>> different. On x86, a CPU that is online and in use can be moved >>> between halted and non-halted state many times a second. >>> >>> If that's the case, we can probably fix this without breaking >>> existing code: explicitly documenting the semantics of >>> "vcpu.<n>.halted" at virConnectGetAllDomainStats() to mean "not >>> online" (i.e. the s390 semantics, not the x86 one), and making >>> qemuMonitorGetCpuHalted() s390-specific. >>> >>> Possibly a better long-term solution is to deprecate >>> "vcpu.<n>.halted" and make "vcpu.<n>.state" work correctly on >>> s390> >> As it seems that nobody was ever *really* interested in x86.halted, one >> could also return 0 unconditionally there (and for other >> expensive-to-query arches)? > > The most important question I have is: does this solution satisfy the > needs of upper management? That is, if we implement the solution suggested > by Eduardo than the feature of automatically hotplugging more CPUs > will only work for s390. Is this OK? > > If yes, then I think this is the best solution. And the next question > would be: Viktor, can you change this in libvirt while we fix query-cpus > in QEMU? > The latest proposal was to use a flag for query-cpus (like full-state) which would control the set of properties queried and reported. If this is the way we decide to go, I can make the necessary changes in libvirt.

> Btw, I guess OpenStack ran into this issue just because this field > slipped into domstats API and ceilometer issues that command... > >>> It would be also interesting to update QEMU QMP documentation to >>> clarify the arch-specific semantics of "halted". >>> >> >> >