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

[Viktor Mihajlovski]

On 29.07.2016 08:30, Peter Krempa wrote:
> 
> So I was testing the data reported from the monitor while doing some
> work on othe vCPU hotplug series and found that for x86 the halted state
> is reported if the CPU is idle and thus halted.  This state it therefore
> almost always reported when the VM is idle.
> 
> Quoting conversation on previous version [1]:
> 
>>> 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.
> 
> While for the s390 platform the state may reasonably express that the
> vcpu is unused, other platforms have apparently different meaning.
I agree, however I haven't claimed that s390x and x86 use the same
mechanism or have the same semantics, even if in both cases the CPUs are
doing "nothing" (in the x86 case in a much more transient way).
> 
> Addditionally on x86_64 if the cpu is hotplugged but not grabbed by the
> guest it is reporting non-halted state.
> 
I don't have a current x86 QEMU setup to check with, but I am wondering
what the CPU thread is actually doing (actively looping?) if it's not
executing the HLT instruction. Anyway, it may be a correct
representation of the CPU doing "something".
>> This information can be used by a libvirt client application for
>> hotplugging decisions, and this is in fact the intention.
> 
> Wouldn't it be possible for you to use the virDomainGetGuestVcpus [2]
> API to determine this information more reliably using the guest agent?
As I said, on s390x the hypervisor-reported state IS reliable. Requiring
the guest agent may not be acceptable for all use cases.
> 
> I'm also a bit worried that the new state might cause problems with
> older apps actually using the value for any reason.
That could of course be, but otoh apps should really not assume that
enumerations like the cpu state will never be extended. virsh is a nice
example showing how to deal with it.
> 
> Said that. I still keep the series in a branch and I'll post a updated
> version including rebase on top of the oncomming vCPU hotplug series
> once I finish it since it completely rewrites the exact part of the
> monitor code requesting the information due to changes necessary to
> detect hotpluggable cpus in recent qemu.
Great, looking forward to it.
> 
> Peter
> 
> [1] https://www.redhat.com/archives/libvir-list/2016-July/msg00234.html
> [2] http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetGuestVcpus
> 


-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294