Re: [Qemu-devel] Re: [PATCH 1/3] Make kvm64 the default cpu model when kvm_enabled()

[Blue Swirl <blauwirbel@gmail.com>]

On Mon, Oct 18, 2010 at 2:16 PM, Anthony Liguori
<aliguori@linux.vnet.ibm.com> wrote:
> On 10/18/2010 03:22 AM, Roedel, Joerg wrote:
>>
>> (Sorry for the late reply)
>>
>> On Thu, Oct 07, 2010 at 08:48:06AM -0400, Anthony Liguori wrote:
>>
>>>
>>> On 10/07/2010 03:42 AM, Roedel, Joerg wrote:
>>>
>>>>
>>>> On Wed, Oct 06, 2010 at 03:24:59PM -0400, Anthony Liguori wrote:
>>>>
>>>>
>>>>>>>
>>>>>>> +    qemu_compat_version = machine->compat_version;
>>>>>>> +
>>>>>>>        if (display_type == DT_NOGRAPHIC) {
>>>>>>>            if (default_parallel)
>>>>>>>                add_device_config(DEV_PARALLEL, "null");
>>>>>>> --
>>>>>>> 1.7.0.4
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Looks fine to me, given CPUs are not in qdev. Anthony?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> The idea is fine, but why not just add the default CPU to the machine
>>>>> description?
>>>>>
>>>>>
>>>>
>>>> If I remember correctly the reason was that the machine description was
>>>> not accessible in the cpuid initialization path because it is a function
>>>> local variable.
>>>>
>>>
>>> Not tested at all but I think the attached patch addresses it in a
>>> pretty nice way.
>>>
>>> There's a couple ways you could support your patch on top of this.  You
>>> could add a kvm_cpu_model to the machine structure that gets defaulted
>>> too if kvm_enabled().  You could also introduce a new KVM machine type
>>> that gets defaulted to if no explicit machine is specified.
>>>
>>
>> I had something similar in mind but then I realized that we need at
>> least a cpu_model and a cpu_model_kvm to distinguish between the TCG and
>> the KVM case.
>>
>
> I would think that having different default machines for KVM and TCG would
> be a better solution.
>
>> Further the QEMUMachine data structure is used for all architectures in
>> QEMU and the model-names only make sense for x86.
>
> SPARC uses cpu_model too FWIW.  I believe Blue Swirl has even discussed
> using a feature-format similar to how x86 does it for SPARC CPUs.

Actually I copied Sparc feature support from x86. Generic feature
support would be nice.