Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..

[Andre Przywara]

john cooper wrote:
> Chris Wright wrote:
> > * Daniel P. Berrange (address@hidden) 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