Re: [Qemu-devel] [PATCH qom-next 08/12] target-i386: introduce cpu-model property for x86_cpu

["Andreas Färber" <afaerber@suse.de>]

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