From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luiz Capitulino Subject: Re: [libvirt] [RFC] kvm: x86: export vCPU halted state to sysfs Date: Fri, 2 Feb 2018 09:55:23 -0500 Message-ID: <20180202095523.3ff36641@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Krempa , kvm@vger.kernel.org, Radim =?UTF-8?B?S3LEjW3DocWZ?= , libvir-list@redhat.com, Viktor, qemu-devel@nongnu.org, Christian Borntraeger , pbonzini@redhat.com, Peter To: Eduardo Habkost 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 T24gRnJpLCAyIEZlYiAyMDE4IDEyOjUwOjE0IC0wMjAwCkVkdWFyZG8gSGFia29zdCA8ZWhhYmtv c3RAcmVkaGF0LmNvbT4gd3JvdGU6Cgo+IChDQ2luZyBxZW11LWRldmVsKQo+IAo+IE9uIEZyaSwg RmViIDAyLCAyMDE4IGF0IDA5OjIxOjU5QU0gLTA1MDAsIEx1aXogQ2FwaXR1bGlubyB3cm90ZToK PiA+IE9uIEZyaSwgMiBGZWIgMjAxOCAxNDoxOTozOCArMDAwMAo+ID4gRGFuaWVsIFAuIEJlcnJh bmfDqSA8YmVycmFuZ2VAcmVkaGF0LmNvbT4gd3JvdGU6ICAKPiA+ID4gT24gRnJpLCBGZWIgMDIs IDIwMTggYXQgMTI6MTU6NTRQTSAtMDIwMCwgRWR1YXJkbyBIYWJrb3N0IHdyb3RlOiAgCj4gWy4u Ll0KPiA+ID4gPiBJdCB3b3VsZCBiZSBhbHNvIGludGVyZXN0aW5nIHRvIHVwZGF0ZSBRRU1VIFFN UCBkb2N1bWVudGF0aW9uIHRvCj4gPiA+ID4gY2xhcmlmeSB0aGUgYXJjaC1zcGVjaWZpYyBzZW1h bnRpY3Mgb2YgImhhbHRlZCIuICAgIAo+ID4gPiAKPiA+ID4gQW55IGFsc28gZXNwZWNpYWxseSBj bGFyaWZ5IHRoZSBhd2Z1bCBwZXJmb3JtYW5jZSBpbXBsaWNhdGlvbnMgb2YgcnVubmluZwo+ID4g PiB0aGlzIHBhcnRpY3VsYXIgcXVlcnkgY29tbWFuZC4gSW4gZ2VuZXJhbCBJIHdvdWxkIG5vdCBl eHBlY3QgcXVlcnkteHh4Cj4gPiA+IG1vbml0b3IgY29tbWFuZHMgdG8gaW50ZXJydXB0IGFsbCB2 Y3B1cywgc28gd2Ugc2hvdWxkIGNsZWFybHkgd2FybiBhYm91dAo+ID4gPiB0aGlzICEgIAo+ID4g Cj4gPiBPciBkZXByZWNhdGUgaXQuLi4gIAo+IAo+IFdlIGNvdWxkIGRlcHJlY2F0ZSB0aGUgZXhw ZW5zaXZlIGZpZWxkcyBvbiBxdWVyeS1jcHVzLCBhbmQgbW92ZQo+IHRoZW0gdG8gYSBtb3JlIGV4 cGVuc2l2ZSBxdWVyeS1jcHUtc3RhdGUgY29tbWFuZC4gIEkgYmVsaWV2ZSBtb3N0Cj4gdXNlcnMg b2YgcXVlcnktY3B1cyBhcmUgb25seSBpbnRlcmVzdGVkIGluIHFvbV9wYXRoLCB0aHJlYWRfaWQs Cj4gYW5kIHRvcG9sb2d5IGluZm8uCgpBZ3JlZS4gVGhlIG9ubHkgdGhpbmcgSSdtIHVuc3VyZSBh Ym91dCBpcyB0aGF0LCBpcyB0aGUgcGVyZm9ybWFuY2UKaXNzdWUgb25seSBwcmVzZW50IGluIHg4 Nj8gSWYgeWVzLCB0aGVuIGRvIHdlIGRlcHJlY2F0ZSBpdCBvbmx5CmZvciB4ODYgb3IgZm9yIGFs bCBhcmNocz8gTWF5YmUgZm9yIGFsbCBhcmNocywgb3RoZXJ3aXNlIHRoaXMgaGFzCnRoZSBwb3Rl bnRpYWwgdG8gdHVybiBpbnRvIGEgbWVzcy4KCj4gTWFya3VzLCBFcmljOiBmcm9tIHRoZSBRQVBJ IHBvaW50IG9mIHZpZXcsIGlzIGl0IE9LIHRvIHJlbW92ZQo+IGZpZWxkcyBiZXR3ZWVuIFFFTVUg dmVyc2lvbnMsIGFzIGxvbmcgYXMgd2UgZm9sbG93IG91cgo+IGRlcHJlY2F0aW9uIHBvbGljeT8K CkkgZ3Vlc3Mgd2UgY2FuJ3QgcmVtb3ZlIGZpZWxkcywgYnV0IG1heWJlIHdlIGNvdWxkIGFsd2F5 cyByZXR1cm4KInJ1bm5pbmciIGFuZCBza2lwIGludGVycnVwdGluZyB0aGUgdkNQVSB0aHJlYWRz LgoKLS0KbGlidmlyLWxpc3QgbWFpbGluZyBsaXN0CmxpYnZpci1saXN0QHJlZGhhdC5jb20KaHR0 cHM6Ly93d3cucmVkaGF0LmNvbS9tYWlsbWFuL2xpc3RpbmZvL2xpYnZpci1saXN0 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehckX-0002Lj-Qg for qemu-devel@nongnu.org; Fri, 02 Feb 2018 09:55:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehckT-0000q6-Un for qemu-devel@nongnu.org; Fri, 02 Feb 2018 09:55:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53113) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ehckT-0000pi-Or for qemu-devel@nongnu.org; Fri, 02 Feb 2018 09:55:29 -0500 Date: Fri, 2 Feb 2018 09:55:23 -0500 From: Luiz Capitulino Message-ID: <20180202095523.3ff36641@redhat.com> In-Reply-To: <20180202145014.GI26425@localhost.localdomain> 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] kvm: x86: export vCPU halted state to sysfs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: "Daniel P. =?UTF-8?B?QmVycmFuZ8Op?=" , Viktor Mihajlovski , Radim =?UTF-8?B?S3LEjW3DocWZ?= , kvm@vger.kernel.org, pbonzini@redhat.com, Peter Krempa , John Ferlan , libvir-list@redhat.com, Christian Borntraeger , qemu-devel@nongnu.org, Markus Armbruster , Eric Blake On Fri, 2 Feb 2018 12:50:14 -0200 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: =20 > > > On Fri, Feb 02, 2018 at 12:15:54PM -0200, Eduardo Habkost wrote: =20 > [...] > > > > It would be also interesting to update QEMU QMP documentation to > > > > clarify the arch-specific semantics of "halted". =20 > > >=20 > > > Any also especially clarify the awful performance implications of run= ning > > > this particular query command. In general I would not expect query-xxx > > > monitor commands to interrupt all vcpus, so we should clearly warn ab= out > > > this ! =20 > >=20 > > Or deprecate it... =20 >=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. Agree. The only thing I'm unsure about is that, is the performance issue only present in x86? If yes, then do we deprecate it only for x86 or for all archs? Maybe for all archs, otherwise this has the potential to turn into a mess. > 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? I guess we can't remove fields, but maybe we could always return "running" and skip interrupting the vCPU threads.