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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
