Re: [Qemu-devel] [PATCH 2/2] qemu-kvm: Add svm cpuid features

[Alexander Graf]

On 12.09.2010, at 08:05, Avi Kivity wrote:

> On 09/11/2010 05:20 PM, Joerg Roedel wrote:
>> On Sat, Sep 11, 2010 at 03:43:02PM +0200, Alexander Graf wrote:
>>>> @@ -305,6 +322,8 @@ static x86_def_t builtin_x86_defs[] = {
>>>>                     CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
>>>>         .ext3_features = CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM |
>>>>             CPUID_EXT3_ABM | CPUID_EXT3_SSE4A,
>>>> +        .svm_features = CPUID_SVM_NPT | CPUID_SVM_LBRV | 
>>>> CPUID_SVM_NRIPSAVE |
>>>> +            CPUID_SVM_VMCBCLEAN,
>>> Does that phenom already do all those? It does NPT, but I'm not sure
>>> about NRIPSAVE for example.
>> Depends on which Phenom you have. A Phenom II has NRIPSAVE but the old
>> Phenoms don't have it. For the SVM features it is not that important
>> what the host hardware supports but what KVM can emulate. VMCBCLEAN can
>> be emulated without supporting it in the host for example.
> 
> Well, let's have a phenom2 type for those new features (and any other 
> features the phenom 2 has).  What's the point of using the name of existing 
> hardware if it doesn't match that hardware?

Isn't that what cpu=host is there for? I don't want to see cpu type cluttering 
like we have it on ppc. I added the core2duo type for Mac OS X guests for which 
those are basically the oldest supported CPUs.

For the Phenom type, I honestly don't remember why, but there was also a good 
reason to add it. In fact, I use it today to have nested virt without -cpu host 
on hardware that's too new for my guests.

Either way, I don't think we need a phenom2 type. The features additional are 
minor enough to not really matter and all use cases I can come up with require 
either -cpu host (local virt) or -cpu phenom (migration).


Alex