From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
John Cooper <john.cooper@redhat.com>,
dlaor@redhat.com, qemu-devel@nongnu.org,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Date: Tue, 05 Jan 2010 18:10:10 -0600 [thread overview]
Message-ID: <4B43D4E2.9050102@codemonkey.ws> (raw)
In-Reply-To: <4B31F1BA.10005@redhat.com>
On 12/23/2009 04:32 AM, Avi Kivity wrote:
> On 12/22/2009 06:12 PM, Anthony Liguori wrote:
>>
>> I think the only two Fully Correct approachs are to support a very
>> specific CPU (e.g. Xeon-X5270) or provide the ability to individually
>> tweak cpu flags.
>
> Yes. By a curious coincidence these are what the hardware vendors
> define (unlike compat classes etc.).
Whenever possible, steal from what the hardware vendors do :-)
>> The notion of compatibility classes should probably be left to
>> management tools. We can make it a lot easier for them though by
>> supporting turning point CPU models.
>
> Agreed.
>
>>
>> For instance, Xeon-X5570 should be a least common denominator for
>> Nehalem processors. It's probably better for users too. It's easier
>> for them to answer "do I have anything older than a Xeon-X5570" than
>> to ask "do I have any Woodcrest class processors".
>>
>> I encounter this confusion a lot. I usually ask people whether they
>> have a Nehalem processor when debugging something and their response
>> is always, I have a Xeon-XYZ, is that Nehalem?
>
> This is complicated by the fact that processors don't have
> straight-line development, and that marketing names don't correspond
> to anything. For example Xeon can be any of the Pentium 4, Core, Core
> 2, and Nehalem (and perhaps other) microachitectures. A newer Xeon is
> often introduced with an older core (usually for larger machines) than
> previously existing Xeons.
Typically, there is at least a little sanity naming for these cases.
For instance, any Xeon W35xx should have the same features. A Xeon
W55xx may be different.
It's not going to be easy to include every possible model. It's a hard
problem for management tools too. The thing is, I imagine most
management tools are going to cat /proc/cpuinfo to get what the
processor is and that's going to be a Xeon YYXXXX type name so I really
believe that's the thing that makes sense to expose in QEMU.
Maybe we could name models like IntelXeonW35xx.
Clever use of the preprocessor will make this effort much, much saner.
Also, we really need some sort of human readable document that explains
the differences between processor classes and makes recommendations
about what management tools should take into consideration.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2010-01-06 0:10 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-14 19:35 [Qemu-devel] cpuid problem in upstream qemu with kvm Michael S. Tsirkin
2009-12-14 19:44 ` Anthony Liguori
2009-12-14 19:44 ` Michael S. Tsirkin
2009-12-14 19:57 ` Anthony Liguori
2009-12-14 20:00 ` Gleb Natapov
2009-12-14 20:02 ` Anthony Liguori
2009-12-14 20:08 ` Gleb Natapov
2009-12-14 20:14 ` Michael S. Tsirkin
2009-12-14 20:10 ` Michael S. Tsirkin
2009-12-14 20:18 ` Anthony Liguori
2009-12-14 20:31 ` Michael S. Tsirkin
2009-12-14 20:54 ` Anthony Liguori
2009-12-14 21:10 ` Michael S. Tsirkin
2009-12-14 21:49 ` Anthony Liguori
2009-12-15 14:28 ` Michael S. Tsirkin
2009-12-15 17:37 ` Anthony Liguori
2009-12-15 17:56 ` Michael S. Tsirkin
2009-12-20 9:42 ` Avi Kivity
2009-12-20 9:49 ` Avi Kivity
2009-12-20 14:48 ` Anthony Liguori
2009-12-20 14:55 ` Avi Kivity
2009-12-20 15:33 ` Anthony Liguori
2009-12-20 15:36 ` Avi Kivity
2009-12-20 15:38 ` Gleb Natapov
2009-12-20 15:40 ` Avi Kivity
2009-12-20 15:49 ` Michael S. Tsirkin
2009-12-20 15:53 ` Avi Kivity
2009-12-20 15:51 ` Michael S. Tsirkin
2009-12-20 15:59 ` Avi Kivity
2009-12-20 16:56 ` Michael S. Tsirkin
2009-12-20 17:17 ` Alexander Graf
2009-12-20 17:18 ` Michael S. Tsirkin
2009-12-20 17:23 ` Alexander Graf
2009-12-20 17:23 ` Gleb Natapov
2009-12-20 17:29 ` Alexander Graf
2009-12-20 17:37 ` Gleb Natapov
2009-12-20 17:59 ` Anthony Liguori
2009-12-20 18:06 ` Alexander Graf
2009-12-21 7:48 ` Gleb Natapov
2009-12-21 13:25 ` [Qemu-devel] " Paolo Bonzini
2009-12-20 18:12 ` [Qemu-devel] " Michael S. Tsirkin
2009-12-21 7:43 ` Gleb Natapov
2009-12-21 8:28 ` Dor Laor
2009-12-21 22:51 ` john cooper
2009-12-22 13:54 ` Dor Laor
2009-12-22 15:19 ` john cooper
2009-12-22 16:12 ` Anthony Liguori
2010-01-05 6:06 ` john cooper
2010-01-06 8:02 ` [Qemu-devel] " Paolo Bonzini
[not found] ` <4B31F1BA.10005@redhat.com>
2010-01-06 0:10 ` Anthony Liguori [this message]
2010-01-06 3:25 ` [Qemu-devel] " Avi Kivity
2010-01-06 13:25 ` Anthony Liguori
2010-01-06 13:35 ` Michael S. Tsirkin
2010-01-06 13:47 ` Avi Kivity
2010-01-06 13:49 ` Anthony Liguori
2010-01-06 13:54 ` Avi Kivity
2010-01-06 13:55 ` Alexander Graf
2010-01-06 13:58 ` Avi Kivity
2010-01-06 14:22 ` Michael S. Tsirkin
2010-01-06 14:32 ` Avi Kivity
2010-01-06 14:48 ` Dor Laor
2010-01-06 15:16 ` Anthony Liguori
2010-01-07 8:03 ` Dor Laor
2010-01-07 8:18 ` Avi Kivity
2010-01-07 9:11 ` Dor Laor
2010-01-07 9:24 ` Avi Kivity
2010-01-07 9:40 ` Dor Laor
2010-01-07 11:39 ` Anthony Liguori
2010-01-07 11:44 ` Dor Laor
2010-01-07 12:00 ` Avi Kivity
2010-01-07 12:20 ` Dor Laor
2010-01-07 12:33 ` Anthony Liguori
2010-01-07 12:40 ` Avi Kivity
2010-01-07 12:47 ` Daniel P. Berrange
2010-01-07 12:50 ` Avi Kivity
2010-01-07 13:14 ` Anthony Liguori
2010-01-07 13:42 ` Dor Laor
2010-01-11 13:26 ` Markus Armbruster
2010-01-07 11:59 ` Avi Kivity
2010-01-07 12:17 ` Dor Laor
2010-01-07 8:24 ` Daniel P. Berrange
2010-01-07 9:13 ` Dor Laor
2010-01-06 15:02 ` Michael S. Tsirkin
2010-01-06 15:12 ` Anthony Liguori
2010-01-06 9:44 ` Daniel P. Berrange
2010-01-06 9:54 ` Avi Kivity
2010-01-06 10:21 ` Daniel P. Berrange
2010-01-06 10:25 ` Avi Kivity
2010-01-06 16:19 ` Lennart Sorensen
2009-12-21 11:15 ` Avi Kivity
2009-12-21 12:59 ` Andre Przywara
2009-12-21 16:14 ` Avi Kivity
2009-12-22 23:02 ` Jamie Lokier
2009-12-21 11:12 ` Avi Kivity
2009-12-21 11:18 ` Michael S. Tsirkin
2009-12-21 11:22 ` Alexander Graf
2009-12-21 11:38 ` Michael S. Tsirkin
2009-12-21 11:45 ` Alexander Graf
2009-12-21 12:02 ` Michael S. Tsirkin
2009-12-22 22:52 ` Jamie Lokier
2009-12-21 12:05 ` Avi Kivity
2009-12-21 13:45 ` David S. Ahern
2009-12-21 13:51 ` Michael S. Tsirkin
2009-12-21 14:07 ` David S. Ahern
2009-12-21 16:11 ` Avi Kivity
2009-12-21 12:04 ` Avi Kivity
2009-12-21 12:04 ` Michael S. Tsirkin
2009-12-21 12:09 ` Avi Kivity
2009-12-21 12:17 ` Michael S. Tsirkin
2009-12-21 11:38 ` Yaniv Kaul
2009-12-21 13:31 ` [Qemu-devel] " Paolo Bonzini
2009-12-22 22:56 ` Jamie Lokier
2009-12-16 14:23 ` [Qemu-devel] " Andre Przywara
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=4B43D4E2.9050102@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=dlaor@redhat.com \
--cc=gleb@redhat.com \
--cc=john.cooper@redhat.com \
--cc=mst@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).