On Thu, Jul 25, 2013 at 11:14:16AM +0200, Andreas Färber wrote: > 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. I still don't see how the above would solve the bigger problem: libvirt needs a way to find out how exactly "-machine foo-1.0 -cpu bar" looks different from "-machine foo-1.1 -cpu bar", but don't want to execute QEMU multiple times just to find that out. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list