On 02.02.2018 17:01, Luiz Capitulino wrote:
> On Fri, 2 Feb 2018 15:54:15 +0000
> Daniel P. Berrangé <berra...@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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to