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

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:

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