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

[Avi Kivity]

 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.

> 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?

> 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.

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