
On Mon, 10 Feb 2014 01:23:37 +0100 Andreas Färber <afaerber@suse.de> wrote:
Am 31.01.2014 19:13, schrieb Eduardo Habkost:
Register separate QOM classes for each x86 CPU model.
This will allow management code to more easily probe what each CPU model provides, by simply creating objects using the appropriate class name, without having to restart QEMU.
This also allows us to eliminate the qdev_prop_set_globals_for_type() hack to set CPU-model-specific global properties.
Instead of creating separate class_init functions for each class, I just used class_data to store a pointer to the X86CPUDefinition struct for each CPU model. This should make the patch shorter and easier to review. Later we can gradually convert each X86CPUDefinition field to lists of per-class property defaults.
Written based on the ideas from the patch "[RFC v5] target-i386: Slim conversion to X86CPU subclasses + KVM subclasses" written by Andreas Färber <afaerber@suse.de>, Igor Mammedov <imammedo@redhat.com>.
The "host" CPU model is special, as the feature flags depend on KVM being initialized. So it has its own class_init and instance_init function, and feature flags are set on instance_init instead of class_init.
Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> --- This patch is similar to the one sent by Andrea and then later resubmitted by Igor as "[RFC v5] target-i386: Slim conversion to X86CPU subclasses + KVM subclasses", as it doesn't create one new class_init function for each subclass.
Main differences v5 -> v6 are: * Code was written from scratch (instead of using the previous patches as base) * I didn't mean to rewrite it entirely, but when doing additional simplification of the CPU init logic on other patches, I ended up rewriting it. * I chose to keep the Signed-off-by lines because I built upon Andreas's and Igor's ideas. Is that OK?
Yes, your From and our Sobs in order is the expected way in this case. If Igor agrees I would propose to drop the textual repetition of this. I'm ok with it, but it doesn't matter since this part is under ---, so it's dropped at commit time anyway.