On Tue, Jul 31, 2012 at 03:22:59PM +0200, Igor Mammedov wrote: > On Thu, Jul 26, 2012 at 10:48:45AM -0400, Eduardo Habkost wrote: > ... > > > > [1] There are multiple changes I want to make the cpudef config format: > > > > - Make it based on boolean per-feature flags, not low-level > > feature_<register> bits > I'm trying to convert features to properties before looking at global props. > current state is at https://github.com/imammedo/qemu/tree/x86-cpu-properties.WIP > Does it represent something you have in mind? Yes, it's like what I have in mind. But note that cpudefs are not objects, yet. We have lots of people focusing on the CPU objects themselves, but the cpudefs read from the config are still plain old structs, with no properties, and there's no clear plan on how to model them in the code. Even if we convert the cpudefs to become classes, we still don't have a simple way to make the cpudef read from the config file set CPU properties only for specific classes. Some of the approaches I see: - Make classes have properties, too; - Make cpudefs be full-featured objects, that are used as argument when creating CPU objects; - Do it manually: have a feature bitmap (or other data structure) for each CPU class, translate the cpudef config options to that bitmap manually, and translate it to CPU features manually when creating the CPU object; - Translate all the cpudef sections to global properties, that would in turn set CPU properties once the CPU objects are created. The last option seems to work (once we make the CPU objects really able to use global properties). But I have the feeling that setting lots of global properties by default is an abuse of the global property system. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list