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

[Avi Kivity]

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