On 09/29/2016 11:04 AM, Peter Krempa wrote:
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.
Hence the sly comment to document the various differences! Seems it may be more of an "idle" or "active" detector for x86 and if it were to be added, then a new "stats" value would be created rather than sharing/using the existing State which is really a detector of vcpu running or offline for most hypervisors (xen added BLOCKED).
# 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.
Again - if something were to be added, then it's a stats only value. That value would need to be well described for the various cpu architectures (and it'd be qemu biased). Cannot extend _virVcpuInfo since it's allocated as a contiguous array and who's to say which side has which version. John