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

[John Ferlan]

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.

John


> 
> Viktor Mihajlovski (4):
>   domain: Add new VCPU state "halted"
>   qemu: Add monitor support for CPU halted state
>   qemu: Add domain support for VCPU halted state
>   qemu: Ensure reported VCPU state is current in driver API
> 
>  include/libvirt/libvirt-domain.h |  1 +
>  src/qemu/qemu_domain.c           | 69 ++++++++++++++++++++++++++++++++++++++++
>  src/qemu/qemu_domain.h           |  5 +++
>  src/qemu/qemu_driver.c           | 23 ++++++++++++--
>  src/qemu/qemu_monitor.c          |  6 +++-
>  src/qemu/qemu_monitor.h          |  5 +++
>  src/qemu/qemu_monitor_json.c     |  3 ++
>  src/qemu/qemu_monitor_text.c     |  8 ++++-
>  tests/qemumonitorjsontest.c      |  8 ++---
>  tools/virsh-domain.c             |  3 +-
>  10 files changed, 122 insertions(+), 9 deletions(-)
>