From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNLIE-0005AH-U5 for qemu-devel@nongnu.org; Fri, 08 Dec 2017 11:14:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eNLIB-0004tU-Oc for qemu-devel@nongnu.org; Fri, 08 Dec 2017 11:14:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56203) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eNLIB-0004sa-IJ for qemu-devel@nongnu.org; Fri, 08 Dec 2017 11:14:27 -0500 Date: Fri, 8 Dec 2017 14:14:22 -0200 From: Eduardo Habkost Message-ID: <20171208161422.GW3037@localhost.localdomain> References: <20171207174832.42663bef@redhat.com> <20171207170719.GT3037@localhost.localdomain> <20171208141618.11e60846@redhat.com> <20171208155050.1a6db1c2@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171208155050.1a6db1c2@redhat.com> Subject: Re: [Qemu-devel] in a device or CPU instance init/realize, can I rely on something having the BQL or equivalent? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Peter Maydell , QEMU Developers , Paolo Bonzini , Stefan Hajnoczi On Fri, Dec 08, 2017 at 03:50:50PM +0100, Igor Mammedov wrote: > On Fri, 8 Dec 2017 13:19:27 +0000 > Peter Maydell wrote: > > > On 8 December 2017 at 13:16, Igor Mammedov wrote: > > > TBH: > > > I do not recall why we have x86 max/host cpu types do feature > > > loading at realize time instead of at class init like the rest > > > of static cpu types. > > > > class init is too early, IIRC -- it's before KVM has been set up at all. > > that shouldn't be an issue as kvm_ppc_register_host_cpu_type() demonstrates > (i.e. an additional class init at kvm/tcg init time), It is possible, but IMO it's not a good idea. We should be able to enumerate all CPU types before the accelerator has been initialized, so query-cpu-definitions and "-cpu help" will always work. > > so it might be some compat issue or just legacy approach why it > havn't been rewritten to class_init for x86 the way PPC does. > But Eduardo probably knows better if there is anything left that > prevents using class init there. It's the opposite: x86 "host" CPU model used to work the same way as PPC, but we changed it so all classes are registered at type_init()-time. -- Eduardo