On Monday 25 January 2010, Dor Laor wrote:
x86 qemu64
x86 phenom
x86 core2duo
x86kvm64
x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86
On 28.01.2010, at 09:19, Arnd Bergmann wrote:
On Monday 25 January 2010, Dor Laor wrote:
x86 qemu64
x86 phenom
x86 core2duo
x86kvm64
x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86
On 01/28/2010 02:43 AM, Alexander Graf wrote:
On 28.01.2010, at 09:19, Arnd Bergmann wrote:
On Monday 25 January 2010, Dor Laor wrote:
x86 qemu64
x86 phenom
x86 core2duo
x86kvm64
x86 qemu32
x86 coreduo
x86 486
On 01/25/10 23:35, Dor Laor wrote:
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
Another way to look at this is that implementing a somewhat arbitrary
policy within QEMU's .c files is something we should try to avoid.
Implementing arbitrary policy in our default config file is a fine thing
to
On 01/26/2010 02:26 AM, Gerd Hoffmann wrote:
On 01/25/10 23:35, Dor Laor wrote:
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
Another way to look at this is that implementing a somewhat arbitrary
policy within QEMU's .c files is something we should try to avoid.
Implementing arbitrary policy
On 01/21/2010 05:05 PM, Anthony Liguori wrote:
On 01/20/2010 07:18 PM, john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpuname' are just as
unfriendly as each other. The only user friendly option is '-cpu
Dor Laor wrote:
x86 qemu64
x86 phenom
x86 core2duo
x86kvm64
x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86 n270
I wonder if kvm32
On 01/25/2010 03:08 AM, Dor Laor wrote:
qemu-config.[ch], taking a new command line that parses the argument via
QemuOpts, then passing the parsed options to a target-specific function
that then builds the table of supported cpus.
It should just be a matter of adding qemu_cpudefs_opts to
Isn't
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
On 01/25/2010 03:08 AM, Dor Laor wrote:
qemu-config.[ch], taking a new command line that parses the argument via
QemuOpts, then passing the parsed options to a target-specific function
that then builds the table of supported cpus.
It should just
john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu name' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme document
On 01/20/2010 07:18 PM, john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpuname' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a
Anthony Liguori wrote:
On 01/20/2010 07:18 PM, john cooper wrote:
I can appreciate the concern of wanting to get this
as correct as possible.
This is the root of the trouble. At the qemu layer, we try to focus on
being correct.
Management tools are typically the layer that deals
On Thu, Jan 21, 2010 at 2:39 PM, Andre Przywara andre.przyw...@amd.com wrote:
john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu name' are just as
unfriendly as each other. The only user friendly
john cooper wrote:
kvm itself can modify flags exported from qemu to a guest.
I would hope for an option to request that qemu doesn't run if the
guest won't get the cpuid flags requested on the command line.
-- Jamie
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of
john cooper wrote:
I foresee wanting to iterate over the models and pick the latest one
which a host supports - on the grounds that you have done the hard
work of ensuring it is a reasonably good performer, while probably
working on another host of similar capability when a new host is
john cooper wrote:
I can appreciate the argument above, however the goal was
choosing names with some basis in reality. These were
recommended by our contacts within Intel, are used by VmWare
to describe their similar cpu models, and arguably have fallen
to defacto usage as evidenced by such
Jamie Lokier wrote:
Do you mean that more powerful management tools to support safe
migration will maintain _their own_ processor model tables, and
perform their calculations using their own tables instead of querying
qemu, and therefore not have any need of qemu's built in table?
I would
Jamie Lokier wrote:
I think we can all agree that there is no point looking for a familiar
-cpu naming scheme because there aren't any familiar and meaningful names
these days.
Even if we dismiss the Intel coined names as internal
code names, there is still VMW's use of them in this
space
On 01/21/2010 10:43 AM, john cooper wrote:
Anthony Liguori wrote:
On 01/20/2010 07:18 PM, john cooper wrote:
I can appreciate the concern of wanting to get this
as correct as possible.
This is the root of the trouble. At the qemu layer, we try to focus on
being correct.
On 01/19/2010 06:15 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu Nehalem. The whole point of this is
to make things
On Wed, Jan 20, 2010 at 08:21:44AM -0600, Anthony Liguori wrote:
On 01/19/2010 06:15 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu
Jamie Lokier wrote:
Anthony Liguori wrote:
On 01/18/2010 10:45 AM, john cooper wrote:
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
Anthony Liguori wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
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
Jamie Lokier wrote:
john cooper wrote:
As before a cpu feature 'check' option is added which warns when
feature flags (either implicit in a cpu model or explicit on the
command line) would have otherwise been quietly unavailable to a
guest:
# qemu-system-x86_64 ... -cpu Nehalem,check
On Wed, Jan 20, 2010 at 03:09:53PM -0500, john cooper wrote:
Anthony Liguori wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu Nehalem. The whole point of this is
to make things easier for a user and
On 01/20/2010 02:26 PM, Daniel P. Berrange wrote:
To be honest all possible naming schemes for '-cpuname' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme document it. Given
they are all equally unfriendly,
On Monday 18 January 2010, john cooper wrote:
+.name = Conroe,
+.level = 2,
+.vendor1 = CPUID_VENDOR_INTEL_1,
+.vendor2 = CPUID_VENDOR_INTEL_2,
+.vendor3 = CPUID_VENDOR_INTEL_3,
+.family = 6, /* P6 */
+.model = 2,
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu name' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme document it. Given
they are all equally
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu name' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme document it. Given
they are
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 -cpumodel, as an
alternative to the existing use of -cpu qemu64 augmented
with a series of feature flags.
The primary motivation was determination of
* Anthony Liguori (anth...@codemonkey.ws) wrote:
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,...
What name will these users
Anthony Liguori wrote:
On 01/18/2010 10:45 AM, john cooper wrote:
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
Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
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,...
john cooper wrote:
As before a cpu feature 'check' option is added which warns when
feature flags (either implicit in a cpu model or explicit on the
command line) would have otherwise been quietly unavailable to a
guest:
# qemu-system-x86_64 ... -cpu Nehalem,check
warning: host
* Jamie Lokier (ja...@shareable.org) wrote:
Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
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
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
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
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
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
Anthony Liguori wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
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
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
Marcelo Tosatti wrote:
On Mon, Dec 21, 2009 at 01:46:36AM -0500, john cooper wrote:
+{
+.name = Opteron_G2,
+.level = 5,
+.vendor1 = CPUID_VENDOR_INTEL_1,
+.vendor2 = CPUID_VENDOR_INTEL_2,
+.vendor3 = CPUID_VENDOR_INTEL_3,
Silly question: why a
john cooper wrote:
{
+.name = Merom,
+.level = 2,
+.vendor1 = CPUID_VENDOR_INTEL_1,
+.vendor2 = CPUID_VENDOR_INTEL_2,
+.vendor3 = CPUID_VENDOR_INTEL_3,
+.family = 6, /* P6 */
+.model = 2,
+.stepping = 3,
+
On Mon, Dec 21, 2009 at 01:46:36AM -0500, john cooper wrote:
This adds definitions for contemporary processors
which may be 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
On 12/21/2009 08:46 AM, john cooper wrote:
This adds definitions for contemporary processors
which may be selected via -cpumodel, 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
This adds definitions for contemporary processors
which may be 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 for
44 matches
Mail list logo
