On Fri, 8 Dec 2017 14:14:22 -0200 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Fri, Dec 08, 2017 at 03:50:50PM +0100, Igor Mammedov wrote: > > On Fri, 8 Dec 2017 13:19:27 +0000 > > Peter Maydell <peter.mayd...@linaro.org> wrote: > > > > > On 8 December 2017 at 13:16, Igor Mammedov <imamm...@redhat.com> 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. Is it for libvirt convenience, so that it would be able to cache all supported cpus regardless of whether they would actually work or not?
