On Fri, 2 Feb 2018 15:42:49 -0200
Eduardo Habkost <ehabk...@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

libvir-list mailing list

Reply via email to