From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Blake Subject: Re: [libvirt] [RFC] kvm: x86: export vCPU halted state to sysfs Date: Fri, 2 Feb 2018 09:19:22 -0600 Message-ID: <90263e16-cbb8-d7d5-368c-c4e1e72da9ee@redhat.com> References: <20180201125441.2f5b4fdd@redhat.com> <20180201201514.GB660@flask> <20180201202649.GG26425@localhost.localdomain> <20180202141554.GH26425@localhost.localdomain> <20180202141938.GJ15403@redhat.com> <20180202092159.48d9bd4c@redhat.com> <20180202145014.GI26425@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0221786818723738085==" Cc: Peter Krempa , kvm@vger.kernel.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , libvir-list@redhat.com, qemu-devel@nongnu.org, Christian Borntraeger , pbonzini@redhat.com To: Eduardo Habkost , Luiz Capitulino Return-path: In-Reply-To: <20180202145014.GI26425@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============0221786818723738085== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GZNkcXGVjmW0tQWvWAGIFywanyUMY107x" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GZNkcXGVjmW0tQWvWAGIFywanyUMY107x Content-Type: multipart/mixed; boundary="n0hQYoTXfJYv3HrrBc7v8vbpUCAT87ZjL"; protected-headers="v1" From: Eric Blake To: Eduardo Habkost , Luiz Capitulino Cc: =?UTF-8?Q?Daniel_P._Berrang=c3=a9?= , Viktor Mihajlovski , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , kvm@vger.kernel.org, pbonzini@redhat.com, Peter Krempa , John Ferlan , libvir-list@redhat.com, Christian Borntraeger , qemu-devel@nongnu.org, Markus Armbruster Message-ID: <90263e16-cbb8-d7d5-368c-c4e1e72da9ee@redhat.com> Subject: Re: [RFC] kvm: x86: export vCPU halted state to sysfs References: <20180201125441.2f5b4fdd@redhat.com> <20180201201514.GB660@flask> <20180201202649.GG26425@localhost.localdomain> <20180202141554.GH26425@localhost.localdomain> <20180202141938.GJ15403@redhat.com> <20180202092159.48d9bd4c@redhat.com> <20180202145014.GI26425@localhost.localdomain> In-Reply-To: <20180202145014.GI26425@localhost.localdomain> --n0hQYoTXfJYv3HrrBc7v8vbpUCAT87ZjL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 02/02/2018 08:50 AM, Eduardo Habkost wrote: > (CCing qemu-devel) >=20 > On Fri, Feb 02, 2018 at 09:21:59AM -0500, Luiz Capitulino wrote: >> On Fri, 2 Feb 2018 14:19:38 +0000 >> Daniel P. Berrang=C3=A9 wrote: >>> On Fri, Feb 02, 2018 at 12:15:54PM -0200, Eduardo Habkost wrote: > [...] >>>> It would be also interesting to update QEMU QMP documentation to >>>> clarify the arch-specific semantics of "halted". =20 >>> >>> Any also especially clarify the awful performance implications of run= ning >>> this particular query command. In general I would not expect query-xx= x >>> monitor commands to interrupt all vcpus, so we should clearly warn ab= out >>> this ! >> >> Or deprecate it... >=20 > We could deprecate the expensive fields on query-cpus, and move > them to a more expensive query-cpu-state command. I believe most > users of query-cpus are only interested in qom_path, thread_id, > and topology info. >=20 > Markus, Eric: from the QAPI point of view, is it OK to remove > fields between QEMU versions, as long as we follow our > deprecation policy? Removing an output field outright may break a client that depended on the field; so a deprecation period is definitely required there. But it is okay, documentation-wise, to state that a field is output always as 0 for back-compatibility reasons and that modern clients should ignore it (which would then let old clients still parse the field, but no longer see a non-zero value), whether or not we also pursue the deprecation course and eventually remove the field after more releases. See CpuInfo::current, for an example. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org --n0hQYoTXfJYv3HrrBc7v8vbpUCAT87ZjL-- --GZNkcXGVjmW0tQWvWAGIFywanyUMY107x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAlp0gXoACgkQp6FrSiUn Q2qsvgf/dRdvfcjj9Lv7h1iaX06sjR/YoGHkVWwZo12YDcpqv1I9wNAg6P/MdxdP HbeDKYL65OrZajSwozkgMZaQC5jYAIdjUcjcBE8Dw+82ysmaPy1LKEzwv/xJvmXX FpSDn+nmtEVJJe+m8AjoMeXMEohtM+hJv2DmIm5PcFABNCciVrK5UwBmpSask4FE UbzUbRdcBjvC1/dYNIFchHqQntEXDg4bKwuYvbYgNIG8v0lEEcgMMKZ3PDszuW+y 88XsBNA0iLGoxXSL1miB/9dz4zTGwUt7dBz8N44e6OjuKoqMBvpDMnjZBEdtBhWW gQ+OBRKtNaDyudEt7eWC4NDyJ0H1Kw== =/fF2 -----END PGP SIGNATURE----- --GZNkcXGVjmW0tQWvWAGIFywanyUMY107x-- --===============0221786818723738085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0221786818723738085==--