On Fri, 2 Feb 2018 15:42:49 -0200
Eduardo Habkost <ehabkost(a)redhat.com> 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.