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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list