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

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:

# virsh vcpuinfo $dom VCPU: 0 CPU: 7 State: halted CPU time: 84.8s CPU Affinity: yyyyyyyy

... 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)?

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.