[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: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm |
Date: |
Wed, 6 Jan 2010 15:35:27 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
On Wed, Jan 06, 2010 at 07:25:10AM -0600, 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?
The syscall issue shows there are several other things necessary IMO:
- features need to be scoped with Vendor ID as some feature bits might
not be 100% compatible.
- Some features might be emulated. So it's not yes/no but
yes/no/slow and management needs to know IMO.
> 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?
>
>>> Clever use of the preprocessor will make this effort much, much saner.
>>
>> I cringe whenever I read something like this.
>
> :-)
>
> 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, 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 <=
- 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
- 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