On Tue, Oct 13, 2009 at 02:56:41AM -0400, john cooper wrote: > Dor Laor wrote: > > What about another approach for the cpuid issue: > > I think that dealing with specific flags is pretty error prone on all > > levels - virt-mgr, libvirt, qemu, migration, and even the guest. > > ..and performance verification, QA, and the average end user. > Unless we reduce all possible combinations of knob settings > into a few well thought out lumped models the complexity can > be overwhelming.
That is a policy decision for applications to make. libvirt should expose the fine grained named CPU models + arbitrary flags, and other bits of info as appropriate (eg formal model for core/socket topology). Apps can decide whether they want to turn that into a higher level concept where admins pick one of a handful of common setups, or expose the full level of control Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
