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