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