All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@amd.com>
To: john cooper <john.cooper@redhat.com>
Cc: Chris Wright <chrisw@sous-sol.org>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	qemu-devel@nongnu.org, KVM list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Thu, 21 Jan 2010 15:39:36 +0100	[thread overview]
Message-ID: <4B586728.8040600@amd.com> (raw)
In-Reply-To: <4B57AB66.30802@redhat.com>

john cooper wrote:
> Chris Wright wrote:
>> * Daniel P. Berrange (berrange@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 unfriendly, the one that has consistency with vmware
>>> naming seems like a mild winner.
>> Heh, I completely agree, and was just saying the same thing to John
>> earlier today.  May as well be -cpu {foo,bar,baz} since the meaning for
>> those command line options must be well-documented in the man page.
> 
> I can appreciate the concern of wanting to get this
> as "correct" as possible.  But ultimately we just
> need three unique tags which ideally have some relation
> to their associated architectures.  The diatribes
> available from /proc/cpuinfo while generally accurate
> don't really offer any more of a clue to the model
> group, and in their unmodified form are rather unwieldy
> as command line flags.
I agree. I'd underline that this patch is for migration purposes only, 
so you don't want to specify an exact CPU, but more like a class of 
CPUs. If you look into the available CPUID features in each CPU, you 
will find that there are only a few groups, with currently three for 
each vendor being a good guess.
/proc/cpuinfo just prints out marketing names, which have only a mild 
relationship to a feature-related technical CPU model. Maybe we can use 
a generation approach like the AMD Opteron ones for Intel, too.
These G1/G2/G3 names are just arbitrary and have no roots within AMD.

I think that an exact CPU model specification is out of scope for this 
patch and maybe even for QEMU. One could create a database with CPU 
names and associated CPUID flags and provide an external tool to 
generate a QEMU command line out of this. Keeping this database 
up-to-date (especially for desktop CPU models) is a burden that the QEMU 
project does not want to bear.

> 
>> This is from an EVC kb article[1]:
> 
> Here is a pointer to a more detailed version:
> 
>    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003212
> 
> 
> We probably should also add an option to dump out the
> full set of qemu-side cpuid flags for the benefit of
> users and upper level tools.
You mean like this one?
http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg01228.html
Resending this patch set is on my plan for next week. What is the state 
of this patch? Will it go in soon? Then I'd rebase my patch set on top 
of it.

Regards,
Andre.

-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712


WARNING: multiple messages have this Message-ID (diff)
From: Andre Przywara <andre.przywara@amd.com>
To: john cooper <john.cooper@redhat.com>
Cc: Chris Wright <chrisw@sous-sol.org>,
	qemu-devel@nongnu.org, KVM list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Thu, 21 Jan 2010 15:39:36 +0100	[thread overview]
Message-ID: <4B586728.8040600@amd.com> (raw)
In-Reply-To: <4B57AB66.30802@redhat.com>

john cooper wrote:
> Chris Wright wrote:
>> * Daniel P. Berrange (berrange@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 unfriendly, the one that has consistency with vmware
>>> naming seems like a mild winner.
>> Heh, I completely agree, and was just saying the same thing to John
>> earlier today.  May as well be -cpu {foo,bar,baz} since the meaning for
>> those command line options must be well-documented in the man page.
> 
> I can appreciate the concern of wanting to get this
> as "correct" as possible.  But ultimately we just
> need three unique tags which ideally have some relation
> to their associated architectures.  The diatribes
> available from /proc/cpuinfo while generally accurate
> don't really offer any more of a clue to the model
> group, and in their unmodified form are rather unwieldy
> as command line flags.
I agree. I'd underline that this patch is for migration purposes only, 
so you don't want to specify an exact CPU, but more like a class of 
CPUs. If you look into the available CPUID features in each CPU, you 
will find that there are only a few groups, with currently three for 
each vendor being a good guess.
/proc/cpuinfo just prints out marketing names, which have only a mild 
relationship to a feature-related technical CPU model. Maybe we can use 
a generation approach like the AMD Opteron ones for Intel, too.
These G1/G2/G3 names are just arbitrary and have no roots within AMD.

I think that an exact CPU model specification is out of scope for this 
patch and maybe even for QEMU. One could create a database with CPU 
names and associated CPUID flags and provide an external tool to 
generate a QEMU command line out of this. Keeping this database 
up-to-date (especially for desktop CPU models) is a burden that the QEMU 
project does not want to bear.

> 
>> This is from an EVC kb article[1]:
> 
> Here is a pointer to a more detailed version:
> 
>    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003212
> 
> 
> We probably should also add an option to dump out the
> full set of qemu-side cpuid flags for the benefit of
> users and upper level tools.
You mean like this one?
http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg01228.html
Resending this patch set is on my plan for next week. What is the state 
of this patch? Will it go in soon? Then I'd rebase my patch set on top 
of it.

Regards,
Andre.

-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712

  reply	other threads:[~2010-01-21 14:41 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
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 [this message]
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=4B586728.8040600@amd.com \
    --to=andre.przywara@amd.com \
    --cc=anthony@codemonkey.ws \
    --cc=berrange@redhat.com \
    --cc=chrisw@sous-sol.org \
    --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.