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

[Alexander Graf]

Am 12.09.2010 um 10:01 schrieb Avi Kivity <address@hidden>:

> On 09/12/2010 09:16 AM, Alexander Graf wrote:
>>>> 
>>>> 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.
> 
> -cpu host is to all supported features into your guest.
> -cpu phenom is to pretend you are running on a phenom cpu.  This is useful 
> for a migration farm for which the greatest common denominator is a phenom.
> 
> Those are separate use cases.

Exactly. And the benefit from phenom -> phenom2 is so minor that it doesn't 
make sense.

> 
>> 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.
> 
> Curious, what guests balk at modern hardware but are fine with phenom?

Sles11 GA ;).

> 
>> 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).
> 
> I'm fine with this (or with adding phenom2).  But don't make phenom contain 
> flags that real phenoms don't have.

Those were my words :).


Alex
>