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

[Luiz Capitulino]

On Fri, 2 Feb 2018 16:51:23 +0100
Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com> wrote:

> On 02.02.2018 16:22, Luiz Capitulino wrote:
> > On Fri, 2 Feb 2018 16:08:25 +0100
> > Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com> 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.

OK, I thought we were going to do both. Because, if libvirt only wants
the halted field for s390 then why issue query-cpus at all in other archs?

> > 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".
> >>>     
> >>
> >>  
> >   
> 
>