Re: [libvirt] [PATCH V2 0/4]] qemu: report actual vcpu state in virVcpuInfo

On Thu, Sep 29, 2016 at 10:30:07 -0400, John Ferlan wrote: > > > On 09/20/2016 04:10 AM, Viktor Mihajlovski wrote: >> Currently, the virVcpuInfo returned by virDomainGetVcpus() will always >> report a state of VIR_VCPU_RUNNING for each defined domain vcpu even if >> the vcpu is currently in the halted state. >> >> As the monitor interface is in fact reporting the accurate state, it is >> rather easy to transport this information with the existing API. >> >> This is done by >> - adding a new state of VIR_VCPU_HALTED >> - extending the monitor to pass back the halted state for the vcpus >> - adding a new field to the private domain vcpu object reflecting the >> halted state for the vcpu >> - modifying the driver code to report the vcpu state based on the halted >> indicator >> - extending virsh vcpuinfo to also display the halted state >> >> The vcpu state is however not recorded in the internal XML format, since >> the state can change asynchronously (without notification). >> >> V2 is a rebase on top of Peter Krempa's CPU hotplug modernization. > > So, I have a question based on a little bit of testing I did with one of > my guests and reading up on the qemu qapi-schema.json which states: > > # Notes: @halted is a transient state that changes frequently. By the > time the > # data is sent to the client, the guest may no longer be halted. > > > It seems "halted" is returned whenever a vCPU is not actively processing > anything (or not scheduled), which I suppose is "expected" for idle > guests; however, if I used the vcpuinfo command and saw: As it was pointed out in the previous posting the "halted" state has different meaning on certain arches. On intel it states that the cpu is idle and waiting. On s390 it is supposed to mean that the guest did not start using it yet.

> > # virsh vcpuinfo $dom > VCPU: 0 > CPU: 7 > State: halted > CPU time: 84.8s > CPU Affinity: yyyyyyyy I was worried that this exact change would happen at least for x86. I don't think we should do this. This would become misleading to many users. > ... > > I might be concerned that it's not "running" or "running (active)" vs. > "running (inactive)" (or paused or waiting or something to indicate not > actively processing/scheduled). The halted state could be the "norm". > > So is this more of a "stats" type value vs. purely an "info" type value? > Also, considering hotplug differences w/ CPU's for x86, ppc, s390, and > arm - could this be some sort of architecture difference too (I'm using > x86)? See above > > Primarily I'm concerned the transient nature of the field based on > whether something is scheduled for the thread could lead to some > "erroneous" bug reports especially since "running" may not be the > dominant state any more. I fully agree. This does not seem to be a good thing to do mainly because of the x86 implications. I don't think that the benefit for s390 hotplug would outweigh the semantics change for the running state in any way.