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

["Michael S. Tsirkin" <mst@redhat.com>]

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