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

[Avi Kivity <avi@redhat.com>]

On 12/21/2009 02:59 PM, Andre Przywara wrote:
>>
>>> KVM's cpuid filter doesn't help here because it won't attempt to 
>>> mask things like sse3.  It would be insane to emulate sse3 too.
>>
>> It does expose sse3 support (called pni in Linux IIRC).  Not sure if 
>> qemu masks it, but the information is there.
>
> What about using -cpu kvm64?
> This has SSE3 as well as CMPXCHG16, both are available in all VMX/SVM 
> capable machines (as far as I could find out) and in TCG.
> This gives a pretty descent base without loosing many relevant 
> performance features.

Sure.  This gives more performance to users and preserves compatibility 
pretty well.  The disadvantage is that the baseline will recede as more 
processor features are introduced.

>> ...
>>> This is a classic management tool problem and the solution usually 
>>> is a set of heuristics depending on how conservative the target 
>>> audience is.
>>
>> Right.  My concern is with casual users upgrading their machine, not 
>> enterprise users who should be protected by their tools.
> Then what about fixing the CPUID bits to those returned by the KVM 
> module the first time the guest is started? Later you would only use 
> those bits (which may have been cropped) for later restarts of the 
> same guest. If you only upgrade your machine, then there should be no 
> problems.

First, even an upgrade may cause loss of cpuid bits (moving to a 
different vendor).  Second, where do you store those bits?

>
> P.S. What feature bits do we talk about?
> Maybe we should group them and use aliases for those.
> SS_S_E3 and SSE4.x come to mind, are any other bits really relevant? 
> (Or do they justify the pain we have when propagating them?)
> Then we would only need: Athlon64, Core2, Nehalem (and maybe Phenom).

Future bits too, for example AVX.

-- 
error compiling committee.c: too many arguments to function