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

[Anthony Liguori <anthony@codemonkey.ws>]

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?

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