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

[John Ferlan]

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