On 02.02.2018 17:01, Luiz Capitulino wrote:
On Fri, 2 Feb 2018 15:54:15 +0000
Daniel P. Berrangé <berrange(a)redhat.com> wrote:
>>> The most important question I have is: does this solution satisfy the
>>> needs of upper management? That is, if we implement the solution suggested
>>> by Eduardo than the feature of automatically hotplugging more CPUs
>>> will only work for s390. Is this OK?
>>>
>>> If yes, then I think this is the best solution. And the next question
>>> would be: Viktor, can you change this in libvirt while we fix query-cpus
>>> in QEMU?
>>>
>> The latest proposal was to use a flag for query-cpus (like full-state)
>> which would control the set of properties queried and reported. If this
>> is the way we decide to go, I can make the necessary changes in libvirt.
>
> Regardless of whether we add that flag to query-cpus or not, we still have
> the general problem of solving the cross-architecture semantics to be
> more sane.
Let's the both then:
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...
o Deprecate the "halted" field in query-cpus in QEMU. This fixes new
instances of this same problem
That is probably OK, if we can get a replacement (e.g. a new state).
--
Regards,
Viktor Mihajlovski