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

[Dor Laor <dlaor@redhat.com>]

On 01/07/2010 10:24 AM, Daniel P. Berrange wrote:
> On Thu, Jan 07, 2010 at 10:03:28AM +0200, Dor Laor wrote:
>> On 01/06/2010 05:16 PM, Anthony Liguori wrote:
>>> On 01/06/2010 08:48 AM, Dor Laor wrote:
>>>> On 01/06/2010 04:32 PM, Avi Kivity wrote:
>>>>> On 01/06/2010 04:22 PM, Michael S. Tsirkin wrote:
>>>>>>> We can probably default -enable-kvm to -cpu host, as long as we
>>>>>>> explain
>>>>>>> very carefully that if users wish to preserve cpu features across
>>>>>>> upgrades, they can't depend on the default.
>>>>>> Hardware upgrades or software upgrades?
>>>>>
>>>>> Yes.
>>>>>
>>>>
>>>> I just want to remind all the the main motivation for using -cpu
>>>> realModelThatWasOnceShiped is to provide correct cpu emulation for the
>>>> guest. Using a random qemu|kvm64+flag1-flag2 might really cause
>>>> trouble for the guest OS or guest apps.
>>>>
>>>> On top of -cpu nehalem we can always add fancy features like x2apic, etc.
>>>
>>> I think it boils down to, how are people going to use this.
>>>
>>> For individuals, code names like Nehalem are too obscure. From my own
>>> personal experience, even power users often have no clue whether there
>>> processor is a Nehalem or not.
>>>
>>> For management tools, Nehalem is a somewhat imprecise target because it
>>> covers a wide range of potential processors. In general, I think what we
>>> really need to do is simplify the process of going from, here's the
>>> output of /proc/cpuinfo for a 100 nodes, what do I need to pass to qemu
>>> so that migration always works for these systems.
>>>
>>> I don't think -cpu nehalem really helps with that problem. -cpu none
>>> helps a bit, but I hope we can find something nicer.
>>
>> We can debate about the exact name/model to represent the Nehalem
>> family, I don't have an issue with that and actually Intel and Amd
>> should define it.
>>
>> There are two main motivations behind the above approach:
>> 1. Sound guest cpu definition.
>>     Using a predefined model should automatically set all the relevant
>>     vendor/stepping/cpuid flags/cache sizes/etc.
>>     We just can let every management application deal with it. It breaks
>>     guest OS/apps. For instance there are MSI support in windows guest
>>     relay on the stepping.
>>
>> 2. Simplifying end user and mgmt tools.
>>     qemu/kvm have the best knowledge about these low levels. If we push
>>     it up in the stack, eventually it reaches the user. The end user,
>>     not a 'qemu-devel user' which is actually far better from the
>>     average user.
>>
>>     This means that such users will have to know what is popcount and
>>     whether or not to limit migration on one host by adding sse4.2 or
>>     not.
>>
>> This is exactly what vmware are doing:
>>   - Intel CPUs :
>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1991
>>   - AMD CPUs :
>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1992
>>
>> Why should we invent the wheel (qemu64..)? Let's learn from their
>> experience.
>
> NB, be careful to distinguish the different levels of VMwares mgmt stack. In
> terms of guest configuration, VMWare ESX APIs require the management app to
> specify the raw CPUID masks. With VirtualCenter VMotion they defined this
> handful of common Intel/AMD CPU sets, and will automatically classify hosts

Live migration is the prime motivation for it.
In addition, as we all know windows guest do not like to find a new cpu 
every time they boot.

> into one  of these sets and use that to specify a default CPUID mask, in the
> case that the guest does not have an explicit one in its config. This gives
> them good default, out-of-the-box behaviour, while also allowing mgmt apps
> 100% control over each guest's CPUID should they want it.

That's exactly what we need.

>
> Regards,
> Daniel