Am 24.07.2013 20:25, schrieb Eduardo Habkost: > In addition to the "-cpu host" KVM initialization problem, this is an > additional problem with the current interfaces provided by QEMU: > > 1) libvirt needs to query data that depend on chosen machine-type and > CPU model > 2) Some machine-type behavior is code and not introspectable data > * Luckily most of the data we need in this case should/will be > encoded in the compat_props tables. > * In either case, we don't have an API to query for machine-type > compat_props information yet. ... and I don't think we should add such a thing. It is an internal implementation detail, whose results should be inspected instead. > 3) CPU model behavior will be modelled as CPU class behavior. Like > on the machine-type case, some of the CPU-model-specific behavior may > be modelled as code, and not introspectable data. > * However, e may be able to eventually encode most or all of > CPU-model-specific behavior simply as different per-CPU-class > property defaults. > * In either case, we don't have an API for QOM class introspection, > yet. If I understood Anthony correctly on the previous call then that is by design. We have a query-cpu-definitions QMP API to obtain CPU models though. And qom-list-types to discover QOM types. The CPU can then be instantiated via -cpu (the type via -device/-object on other targets), inspected with qom-list/qom-get API and modified with qom-set. The problem with the latter is that devices/CPUs get realized in code rather than shortly before emulation/virtualization starts - that's what my recursive QOM realization series prepared to address, but Paolo veto'ed that and hasn't provided sufficient feedback on what exactly his concerns are founded on and what he proposes instead. In particular: Would walking the qdev bus tree instead of the QOM composition tree address the concerns? Depending on what libvirt is actually trying to do, the above combined with Igor's feature properties and -S might do the job. For x86 the CPUs are easily locatable in the QOM tree via ICC. Regards, Andreas > But there's something important in this case: the resulting CPUID data > for a specific machine-type + CPU-model combination must be always the > same, forever. This means libvirt may even use a static table, or cache > this information indefinitely. > > (Note that I am not talking about "-cpu host", here, but about all the > other CPU models) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list