[libvirt] [PATCH] qemu: report vcpu state in virDomainGetVcpus

[Peter Krempa]

On Fri, Jul 08, 2016 at 16:33:59 +0200, Viktor Mihajlovski wrote:
> On 08.07.2016 15:54, Peter Krempa wrote:
> > On Fri, Jul 08, 2016 at 15:39:00 +0200, Boris Fiuczynski wrote:
> >> From: Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com>
> >>
> >> 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.
> > 
> > Could you please elaborat how you expect to use this info?
> Dpending on the architecture, the halted state is an indication that the
> virtual CPU is not in use. On s390x for example the halted state is only
> reported if the CPU is stopped or in disabled wait, both indicating that
> the virtual CPUs are not enabled for the operating system.
> This information can be used by a libvirt client application for
> hotplugging decisions, and this is in fact the intention.

Okay that sounds reasonable.

> >> 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 array to the private domain object reflecting the halted
> >>   state for the vcpus and update it along with the vcpu pids array
> >> - modifying the driver code to report the vcpu state based on the halted
> >>   indicator
> >> - extending virsh vcpuinfo to also display the halted state
> >> - modifying the monitor_json testcase
> >>
> >> The vcpu state is however not recorded in the internal XML format, since
> >> the state can change asynchronously (without notification).
> > 
> > virDomainGetVcpus does not call qemuDomainDetectVcpuPids nor does not
> > update the info in any way. qemuDomainDetectVcpuPids is called just at
> > startup of the qemu process. As of such this is reporting old data at
> > any time and thus doesn't really make much sense in the current state.
> Well, it's also called in the course of CPU hotplugging to update the
> CPU pids, but you are right in that the info is getting stale quickly.
> > 
> > Please note that calling qemuDomainDetectVcpuPids is not desired in
> > virDomainGetVcpus. You would need to update just the vcpu states.
> > 
> Right, I can add another API to retrieve only the states, still using
> the same monitor interface. I didn't want to break policy (in fact I
> wasn't aware of that particular one), apologies.

Well, there isn't much of a policy at this point. Just that updating of
the thread IDs when not necessary isn't a good approach.

Also please try to base the patch on the series I've posted so I don't
have to rework it completely.