On Fri, 2 Feb 2018 15:42:49 -0200 Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote: > On Fri, Feb 02, 2018 at 05:19:34PM +0100, Viktor Mihajlovski wrote: > > On 02.02.2018 17:01, Luiz Capitulino wrote: > [...] > > > o Make qemuDomainRefreshVcpuHalted() s390-only in libvirt. This by > > > itself fixes the original performance issue > > We are normally trying to avoid architecture-specific code in libvirt > > (not always successfully). We could omit the call, based on a QEMU > > Capability derived from the presence of said flag. This would change the > > libvirt-client side default to not report halted. A client can the still > > request the value via a tbd libvirt flag. Which is what an s390-aware > > management app would have to do... > > The problem I see here is that the current semantics of the > "halted" field in QEMU is arch-specific, so either libvirt or > upper layers will necessarily need arch-specific code if they > want to support QEMU 2.11 or older. My understanding of this plan is: 1. Deprecate the "halted" field in query-cpus (that is, make it always return halted=false) 2. Add a new command, say query-cpu-state, which is arch dependent and is only available in archs that support sane "halted" semantics (I guess we can have per-arch QMP commands, right?) 3. Modify libvirt to use query-cpu-state if it's available, otherwise use query-cpus (in which case "halted" will be bogus, but that's a feature :) ) In essence, we're moving the arch-specific code from libvirt to qemu.
