(Now replying on the right thread, to keep the discussion in the right place. I don't know how I ended up replying to a pre-historic version of the patch, sorry.)
On Tue, Oct 02, 2012 at 05:36:59PM +0200, Igor Mammedov wrote: [...] > @@ -1938,6 +2043,12 @@ static void x86_cpu_initfn(Object *obj) > object_property_add(obj, "tsc-frequency", "int", > x86_cpuid_get_tsc_freq, > x86_cpuid_set_tsc_freq, NULL, NULL, NULL); > + x86_register_cpuid_properties(obj, feature_name); > + x86_register_cpuid_properties(obj, ext_feature_name); > + x86_register_cpuid_properties(obj, ext2_feature_name); > + x86_register_cpuid_properties(obj, ext3_feature_name); > + x86_register_cpuid_properties(obj, kvm_feature_name); > + x86_register_cpuid_properties(obj, svm_feature_name); Stupid question about qdev: - qdev_prop_set_globals() is called from device_initfn() - device_initfn() is called before the child class instance_init() function (x86_cpu_initfn()) - So, qdev_prop_set_globals() gets called before the CPU class properties are registered. So this would defeat the whole point of all the work we're doing, that is to allow compatibility bits to be set as machine-type global properties. But I don't know what's the right solution here. Should the qdev_prop_set_globals() call be moved to qdev_init() instead? Should the CPU properties be registered somewhere else? -- Eduardo
