Am 04.06.2012 16:56, schrieb Igor Mammedov: > On 05/30/2012 05:22 PM, Andreas Färber wrote: >> Am 30.05.2012 00:10, schrieb Igor Mammedov: >>> it's probably intermidiate step till cpu modeled as >>> sub-classes. After then we probably could drop it. >>> >>> However it still could be used for overiding default >>> cpu subclasses definition, and probably renamed to >>> something like 'features'. >> >> * As you rightly point out, we are heading towards sub-classes and that >> contradicts this two-step initialization. I don't see how this is an >> intermediate step? > It's not clear to me how sub-classes contradict with two-step > initialization, > , could you elaborate more on this?
CPU subclasses mean to me that for -cpu qemu64 we would have a QOM type "qemu64" (or so). initfn would then take care of initializing all default values, and from cpu_x86_init() we would parse the remaining cpu_model parameters and set QOM properties on the CPU instance. Original attempt: https://github.com/afaerber/qemu-cpu/commit/a27feda42712606ca2303faeb6c7e8478660a1c1 Now, the contradiction is that once we have done object_new("qemu64") we cannot change its type "qemu64" to anything else. Therefore I dislike sticking cpu_model into a "cpu-model" property. What I was talking about wrt features was doing in pseudocode: object_new("qemu64") object_property_set_int("family", 42) object_property_set_string("vendor", "Me, myself and I") object_property_set_bool("x2apic", true) ... I.e. decoupling the back part of the cpu_model string from the model. My patches in master that you and others have reviewed did this for the mostly numeric CPUID parts (-cpu foo,x=42), with a view to code sharing. What's missing is properties to set CPU features (-cpu foo,+x,-y). There the question is how granular do we want to go and which types do we want to use. The example above shows using a bool property for a specific feature (without having checked that for correctness). Other possibilities would be to have a feature string with all those space-separated acronyms or an int that is a bitfield. One doesn't rule out the other. Jan's requirement, I think, was to be able to set them from global properties for pc-1.x backwards compatibility. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
