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
next prev parent 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: linkBe 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.