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

[Avi Kivity <avi@redhat.com>]

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.

>
> There are two main motivations behind the above approach:
> 1. Sound guest cpu definition.
>    Using a predefined model should automatically set all the relevant
>    vendor/stepping/cpuid flags/cache sizes/etc.
>    We just can let every management application deal with it. It breaks
>    guest OS/apps. For instance there are MSI support in windows guest
>    relay on the stepping.
>
> 2. Simplifying end user and mgmt tools.
>    qemu/kvm have the best knowledge about these low levels. If we push
>    it up in the stack, eventually it reaches the user. The end user,
>    not a 'qemu-devel user' which is actually far better from the
>    average user.
>
>    This means that such users will have to know what is popcount and
>    whether or not to limit migration on one host by adding sse4.2 or
>    not.
>
> 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.

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