[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: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm |
Date: |
Wed, 06 Jan 2010 15:47:19 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 |
On 01/06/2010 03:25 PM, Anthony Liguori wrote:
On 01/05/2010 09:25 PM, Avi Kivity wrote:
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.
While a W3501 should be similar to a W3599, we don't know if it
actually will be. You are no longer on a Fully Correct path and
instead you are wandering in Marketing Land.
Note that the processor type is just part of what determines which
features are exposed to the guest. Qemu version, kvm version, host
kernel version, and even kernel command-line parameters all play a
part, so to really determine migratability the management tool should
talk to qemu, not /proc/cpuinfo.
So if I understand correctly, you're advocating to drop the idea of
common model names, and provide a mechanism for a management tool to
query which cpu features are supported both by the processor, but also
filtered by qemu, kvm, etc?
Well, it's nice to have a -cpu X1234, so I wouldn't recommend dropping
it, but certainly a migration pool that doesn't assume anything about
the host qemu and kernel version needs more fine-grained information.
I think that's workable but I think there may be some subtle issues
especially across qemu versions. Can you give an example of what you
would expect the output to be?
-> { command: query-cpu-capabalities }
<- { result: { features: [vm, fpu, lm, sse2, sse3, sssse3, ssssssse3,
sse3.14 ], cache: { ... }, vendor: { .... }, etc. } }
Or something. We'd need similar queries for the number of PCI slots,
for example, so the GUI can tell the user when adding hardware is no
longer an option instead of trying it blindly and returning an error.
--
error compiling committee.c: too many arguments to function
- 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, 2010/01/05
- 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 <=
- 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
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Dor Laor, 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, Dor Laor, 2010/01/07
- Re: [Qemu-devel] cpuid problem in upstream qemu with kvm, Avi Kivity, 2010/01/07