Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

[Avi Kivity <avi@redhat.com>]

On 01/07/2010 11:11 AM, Dor Laor wrote:
> On 01/07/2010 10:18 AM, Avi Kivity wrote:
>> On 01/07/2010 10:03 AM, Dor Laor wrote:
>>>
>>> We can debate about the exact name/model to represent the Nehalem
>>> family, I don't have an issue with that and actually Intel and Amd
>>> should define it.
>>
>> AMD and Intel already defined their names (in cat /proc/cpuinfo). They
>> don't define families, the whole idea is to segment the market.
>
> The idea here is to minimize the number of models we should have the 
> following range for Intel for example:
>   pentium3 - merom -  penry - Nehalem - host - kvm/qemu64
> So we're supplying wide range of cpus, p3 for maximum flexibility and 
> migration, nehalem for performance and migration, host for maximum 
> performance and qemu/kvm64 for custom maid.

There's no such thing as Nehalem.

>>>
>>> This is exactly what vmware are doing:
>>> - Intel CPUs :
>>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1991 
>>>
>>>
>>> - AMD CPUs :
>>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1992 
>>>
>>>
>>
>> They don't have to deal with different qemu and kvm versions.
>>
>
> Both our customers - the end users. It's not their problem.
> IMO what's missing today is a safe and sound cpu emulation that is 
> simply and friendly to represent. qemu64,+popcount is not simple for 
> the end user. There is no reason to through it on higher level mgmt.

There's no simple solution except to restrict features to what was 
available on the first processors.



-- 
error compiling committee.c: too many arguments to function