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.
--
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