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