[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: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm |
Date: |
Tue, 05 Jan 2010 18:10:10 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
On 12/23/2009 04:32 AM, Avi Kivity wrote:
On 12/22/2009 06:12 PM, Anthony Liguori wrote:
I think the only two Fully Correct approachs are to support a very
specific CPU (e.g. Xeon-X5270) or provide the ability to individually
tweak cpu flags.
Yes. By a curious coincidence these are what the hardware vendors
define (unlike compat classes etc.).
Whenever possible, steal from what the hardware vendors do :-)
The notion of compatibility classes should probably be left to
management tools. We can make it a lot easier for them though by
supporting turning point CPU models.
Agreed.
For instance, Xeon-X5570 should be a least common denominator for
Nehalem processors. It's probably better for users too. It's easier
for them to answer "do I have anything older than a Xeon-X5570" than
to ask "do I have any Woodcrest class processors".
I encounter this confusion a lot. I usually ask people whether they
have a Nehalem processor when debugging something and their response
is always, I have a Xeon-XYZ, is that Nehalem?
This is complicated by the fact that processors don't have
straight-line development, and that marketing names don't correspond
to anything. For example Xeon can be any of the Pentium 4, Core, Core
2, and Nehalem (and perhaps other) microachitectures. A newer Xeon is
often introduced with an older core (usually for larger machines) than
previously existing Xeons.
Typically, there is at least a little sanity naming for these cases.
For instance, any Xeon W35xx should have the same features. A Xeon
W55xx may be different.
It's not going to be easy to include every possible model. It's a hard
problem for management tools too. The thing is, I imagine most
management tools are going to cat /proc/cpuinfo to get what the
processor is and that's going to be a Xeon YYXXXX type name so I really
believe that's the thing that makes sense to expose in QEMU.
Maybe we could name models like IntelXeonW35xx.
Clever use of the preprocessor will make this effort much, much saner.
Also, we really need some sort of human readable document that explains
the differences between processor classes and makes recommendations
about what management tools should take into consideration.
Regards,
Anthony Liguori
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, john cooper, 2010/01/05
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm,
Anthony Liguori <=
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Avi Kivity, 2010/01/05
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Avi Kivity, 2010/01/06
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Avi Kivity, 2010/01/06
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Alexander Graf, 2010/01/06
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Avi Kivity, 2010/01/06
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Avi Kivity, 2010/01/06