[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH qom-next 08/12] target-i386: introduce cpu-model
Re: [Qemu-devel] [PATCH qom-next 08/12] target-i386: introduce cpu-model property for x86_cpu
Mon, 04 Jun 2012 19:29:46 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0
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
> , 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.
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_property_set_string("vendor", "Me, myself and I")
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.
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg