From: Anthony Liguori <anthony@codemonkey.ws>
To: john cooper <john.cooper@redhat.com>
Cc: KVM list <kvm@vger.kernel.org>,
qemu-devel@nongnu.org, "Przywara, Andre" <Andre.Przywara@amd.com>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Tue, 19 Jan 2010 13:39:52 -0600 [thread overview]
Message-ID: <4B560A88.9@codemonkey.ws> (raw)
In-Reply-To: <4B549016.6090501@redhat.com>
On 01/18/2010 10:45 AM, john cooper wrote:
> This is a rework of the prior version which adds definitions
> for contemporary processors selected via -cpu<model>, as an
> alternative to the existing use of "-cpu qemu64" augmented
> with a series of feature flags.
>
> The primary motivation was determination of a least common
> denominator within a given processor class to simplify guest
> migration. It is still possible to modify an arbitrary model
> via additional feature flags however the goal here was to
> make doing so unnecessary in typical usage. The other
> consideration was providing models names reflective of
> current processors. Both AMD and Intel have reviewed the
> models in terms of balancing generality of migration vs.
> excessive feature downgrade relative to released silicon.
>
> Concerning the prior version of the patch, the proposed name
> used for a given model drew a fair amount of debate, the
> main concern being use of names as mnemonic as possible to
> the wisest group of users. Another suggestion was to use
> the vendor name of released silicon corresponding to a least
> common denominator CPU within the class, rational being doing
> so is more definitive of the intended functionality. However
> something like:
>
> -cpu "Intel Core 2 Duo P9xxx"
>
Stick with Xeon naming, it's far less annoying.
> probably isn't all that easy to remember nor type when
> selecting a Penryn class cpu. So I struck what I believe to
> be a reasonable compromise where the original x86_def_t.name
> was for the most part retained with the x86_def_t.model_id
> capturing the marketing name of the cpu being used as the
> least common denominator for the class. To make it easier for
> a user to associate a *.name with *.model_id, "-cpu ?" invoked
> rather as "-cpu ??" will append *.model_id to the generated
> table:
>
> :
> x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
> x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
> x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
> x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron)
> x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron)
> x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron)
> :
>
I'm very much against having -cpu Nehalem. The whole point of this is
to make things easier for a user and for most of the users I've
encountered, -cpu Nehalem is just as obscure as -cpu qemu64,-sse3,+vmx,...
Regards,
Anthony Liguori
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: john cooper <john.cooper@redhat.com>
Cc: "Przywara, Andre" <Andre.Przywara@amd.com>,
qemu-devel@nongnu.org, KVM list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Tue, 19 Jan 2010 13:39:52 -0600 [thread overview]
Message-ID: <4B560A88.9@codemonkey.ws> (raw)
In-Reply-To: <4B549016.6090501@redhat.com>
On 01/18/2010 10:45 AM, john cooper wrote:
> This is a rework of the prior version which adds definitions
> for contemporary processors selected via -cpu<model>, as an
> alternative to the existing use of "-cpu qemu64" augmented
> with a series of feature flags.
>
> The primary motivation was determination of a least common
> denominator within a given processor class to simplify guest
> migration. It is still possible to modify an arbitrary model
> via additional feature flags however the goal here was to
> make doing so unnecessary in typical usage. The other
> consideration was providing models names reflective of
> current processors. Both AMD and Intel have reviewed the
> models in terms of balancing generality of migration vs.
> excessive feature downgrade relative to released silicon.
>
> Concerning the prior version of the patch, the proposed name
> used for a given model drew a fair amount of debate, the
> main concern being use of names as mnemonic as possible to
> the wisest group of users. Another suggestion was to use
> the vendor name of released silicon corresponding to a least
> common denominator CPU within the class, rational being doing
> so is more definitive of the intended functionality. However
> something like:
>
> -cpu "Intel Core 2 Duo P9xxx"
>
Stick with Xeon naming, it's far less annoying.
> probably isn't all that easy to remember nor type when
> selecting a Penryn class cpu. So I struck what I believe to
> be a reasonable compromise where the original x86_def_t.name
> was for the most part retained with the x86_def_t.model_id
> capturing the marketing name of the cpu being used as the
> least common denominator for the class. To make it easier for
> a user to associate a *.name with *.model_id, "-cpu ?" invoked
> rather as "-cpu ??" will append *.model_id to the generated
> table:
>
> :
> x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
> x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
> x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
> x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron)
> x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron)
> x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron)
> :
>
I'm very much against having -cpu Nehalem. The whole point of this is
to make things easier for a user and for most of the users I've
encountered, -cpu Nehalem is just as obscure as -cpu qemu64,-sse3,+vmx,...
Regards,
Anthony Liguori
next prev parent reply other threads:[~2010-01-19 19:39 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-18 16:45 [PATCH] Add definitions for current cpu models john cooper
2010-01-18 16:45 ` [Qemu-devel] " john cooper
2010-01-19 19:39 ` Anthony Liguori [this message]
2010-01-19 19:39 ` Anthony Liguori
2010-01-19 20:03 ` Chris Wright
2010-01-19 22:12 ` Jamie Lokier
2010-01-19 22:12 ` Jamie Lokier
2010-01-19 22:20 ` Chris Wright
2010-01-19 22:20 ` Chris Wright
2010-01-19 22:25 ` Anthony Liguori
2010-01-20 0:15 ` Chris Wright
2010-01-20 0:15 ` Chris Wright
2010-01-20 14:21 ` Anthony Liguori
2010-01-20 14:27 ` Gleb Natapov
2010-01-20 14:27 ` Gleb Natapov
2010-01-20 1:38 ` Jamie Lokier
2010-01-20 1:38 ` Jamie Lokier
2010-01-20 20:09 ` john cooper
2010-01-20 20:26 ` Daniel P. Berrange
2010-01-20 20:26 ` Daniel P. Berrange
2010-01-20 20:53 ` Anthony Liguori
2010-01-20 20:53 ` Anthony Liguori
2010-01-21 0:25 ` Chris Wright
2010-01-21 0:25 ` Chris Wright
2010-01-21 1:18 ` john cooper
2010-01-21 1:18 ` john cooper
2010-01-21 14:39 ` Andre Przywara
2010-01-21 14:39 ` Andre Przywara
2010-01-21 17:06 ` Blue Swirl
2010-01-21 15:05 ` Anthony Liguori
2010-01-21 15:05 ` Anthony Liguori
2010-01-21 16:43 ` john cooper
2010-01-21 16:43 ` john cooper
2010-01-21 18:59 ` Anthony Liguori
2010-01-21 18:59 ` Anthony Liguori
2010-01-25 9:08 ` Dor Laor
2010-01-25 9:08 ` Dor Laor
2010-01-25 11:27 ` Jamie Lokier
2010-01-25 11:27 ` Jamie Lokier
2010-01-25 14:21 ` Anthony Liguori
2010-01-25 14:21 ` Anthony Liguori
2010-01-25 22:35 ` Dor Laor
2010-01-26 8:26 ` Gerd Hoffmann
2010-01-26 8:26 ` Gerd Hoffmann
2010-01-26 12:54 ` Anthony Liguori
2010-01-26 12:54 ` Anthony Liguori
2010-01-28 8:19 ` Arnd Bergmann
2010-01-28 8:19 ` Arnd Bergmann
2010-01-28 8:43 ` Alexander Graf
2010-01-28 8:43 ` Alexander Graf
2010-01-28 10:09 ` Arnd Bergmann
2010-01-28 10:09 ` Arnd Bergmann
2010-01-28 14:10 ` Anthony Liguori
2010-01-28 14:10 ` Anthony Liguori
2010-01-19 22:11 ` Jamie Lokier
2010-01-20 20:09 ` john cooper
2010-01-20 20:09 ` john cooper
2010-01-21 17:50 ` Jamie Lokier
2010-01-21 17:50 ` Jamie Lokier
2010-01-21 18:13 ` Jamie Lokier
2010-01-21 18:13 ` Jamie Lokier
2010-01-21 18:36 ` john cooper
2010-01-21 18:36 ` john cooper
2010-01-19 22:15 ` Jamie Lokier
2010-01-19 22:15 ` Jamie Lokier
2010-01-20 20:11 ` john cooper
2010-01-20 20:11 ` john cooper
2010-01-21 17:55 ` Jamie Lokier
2010-01-21 17:55 ` Jamie Lokier
2010-01-21 18:34 ` john cooper
2010-01-21 18:34 ` john cooper
2010-01-20 23:20 ` Arnd Bergmann
2010-01-20 23:20 ` [Qemu-devel] " Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2009-12-21 6:46 [Qemu-devel] " john cooper
2009-12-24 13:45 ` Avi Kivity
2009-12-31 3:13 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B560A88.9@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=Andre.Przywara@amd.com \
--cc=john.cooper@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.