From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Subject: Re: [RFC] kvm: x86: export vCPU halted state to sysfs Date: Fri, 2 Feb 2018 15:54:15 +0000 Message-ID: <20180202155415.GN15403@redhat.com> References: <20180201125441.2f5b4fdd@redhat.com> <20180201201514.GB660@flask> <20180201202649.GG26425@localhost.localdomain> <20180202141554.GH26425@localhost.localdomain> <96d66ae2-5c51-510f-06a5-cecdda74cfd4@linux.vnet.ibm.com> <20180202102231.7dc9a945@redhat.com> <86571633-ae6d-5678-7611-549ff41dccd8@linux.vnet.ibm.com> Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Luiz Capitulino , Eduardo Habkost , Radim =?utf-8?B?S3LEjW3DocWZ?= , kvm@vger.kernel.org, pbonzini@redhat.com, Peter Krempa , John Ferlan , libvir-list@redhat.com, Christian Borntraeger To: Viktor Mihajlovski Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36468 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751611AbeBBPyY (ORCPT ); Fri, 2 Feb 2018 10:54:24 -0500 Content-Disposition: inline In-Reply-To: <86571633-ae6d-5678-7611-549ff41dccd8@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Feb 02, 2018 at 04:51:23PM +0100, Viktor Mihajlovski wrote: > On 02.02.2018 16:22, Luiz Capitulino wrote: > > On Fri, 2 Feb 2018 16:08:25 +0100 > > Viktor Mihajlovski wrote: > > > >>>> A disabled guest CPU is represented as halted in the QEMU object model > >>>> and can therefore be identified by the QMP query-cpus command. > >>>> > >>>> The initial patch proposal to expose this via virsh vcpuinfo was not > >>>> considered to be desirable because there was a concern that legacy > >>>> management software might be confused seeing halted vcpus. Therefore the > >>>> state information was added to the cpu domain statistics. > >>>> > >>>> One issue we're facing is that the semantics of "halted" are different > >>>> between s390 and at least x86. The question might be whether they are > >>>> different enough to grant a specific "disabled" indicator. > >>> > >>> From your description, it looks like they are completely > >>> different. On x86, a CPU that is online and in use can be moved > >>> between halted and non-halted state many times a second. > >>> > >>> If that's the case, we can probably fix this without breaking > >>> existing code: explicitly documenting the semantics of > >>> "vcpu..halted" at virConnectGetAllDomainStats() to mean "not > >>> online" (i.e. the s390 semantics, not the x86 one), and making > >>> qemuMonitorGetCpuHalted() s390-specific. > >>> > >>> Possibly a better long-term solution is to deprecate > >>> "vcpu..halted" and make "vcpu..state" work correctly on > >>> s390> > >> As it seems that nobody was ever *really* interested in x86.halted, one > >> could also return 0 unconditionally there (and for other > >> expensive-to-query arches)? > > > > 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|