[libvirt] [RFC] kvm: x86: export vCPU halted state to sysfs

Daniel P. Berrangé berrange at redhat.com
Mon Feb 5 13:47:27 UTC 2018


On Mon, Feb 05, 2018 at 02:43:15PM +0100, Viktor Mihajlovski wrote:
> On 02.02.2018 21:41, Eduardo Habkost wrote:
> > On Fri, Feb 02, 2018 at 03:19:45PM -0500, Luiz Capitulino wrote:
> >> On Fri, 2 Feb 2018 18:09:12 -0200
> >> Eduardo Habkost <ehabkost at redhat.com> wrote:
> > [...]
> >>> Your plan above covers what will happen when using newer QEMU
> >>> versions, but libvirt still needs to work sanely if running QEMU
> >>> 2.11.  My suggestion is that libvirt do not run query-cpus to ask
> >>> for the "halted" field on any architecture except s390.
> >>
> >> My current plan is to ask libvirt to completely remove query-cpus
> >> usage, independent of the arch and use the new command instead.
> > 
> > This would be a regression for people running QEMU 2.11 on s390.
> > 
> > (But maybe it would be an acceptable regression?  Viktor, what do
> > you think?  Are there production releases of management systems
> > that already rely on vcpu.<n>.halted?)
> > 
> Unfortunately, there's code out there looking at vcpu.<n>.halted. I've
> informed the product team about the issue.
> 
> If we drop/deprecate vcpu.<n>.halted from the domain statistics, this
> should be done for all arches, if there's a replacement mechanism (i.e.
> new VCPU states). As a stop-gap measure we can make the call
> arch-dependent until the new stuff is in place.

Yes, I think libvirt should just restrict this 'halted' feature reporting
to s390 only, since the other archs have different semantics for this
item, and the s390 semantics are the ones we want.

If we figure out a better solution for gettign the data on s390 then
we can change that to not use query-cpus at all, and possibly extend
it to other archs too.

> BTW: libvirt cannot eliminate query-cpus entirely because initial CPU
> topology and changes due to hotplug must be queried.

At that point, libvirt has not started VCPUS, so we are ok wrt the
performance implications.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list