[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dor Laor
Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Date: Thu, 07 Jan 2010 11:40:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 ThunderBrowse/

On 01/07/2010 11:24 AM, Avi Kivity wrote:
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.

Intel were ok with it. Again, you can name is corei7 or xeon34234234234, I don't care, the principle remains the same.

This is exactly what vmware are doing:
- Intel CPUs :

- AMD CPUs :

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.

What's not simple about the above 4 options?
What's a better alternative (that insures users understand it and use it and guest msi and even skype application is happy about it)?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]