Am 12.09.2010 um 10:01 schrieb Avi Kivity <a...@redhat.com>: > 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 >
