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

[Avi Kivity <avi@redhat.com>]

On 01/06/2010 02:10 AM, Anthony Liguori wrote:
> 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 :-)
>

[...]

> 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.

> Clever use of the preprocessor will make this effort much, much saner.

I cringe whenever I read something like this.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.