[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

From: Daniel P. Berrange
Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Date: Wed, 6 Jan 2010 09:44:14 +0000
User-agent: Mutt/1.4.1i

On Tue, Jan 05, 2010 at 06:10:10PM -0600, Anthony Liguori wrote:
> >>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.

For libvirt, we have an XML database that contains a list of CPU model
names, and (for x86) associated CPU ID flags. The guest XML can specify
a model name, and we'll map that through to the matching QEMU model
name if there's an exact match. Otherwise we'll map it to the closest
QEMU model name + a set of named flags. The guest XML can also contain
a list of named flags ontop of the basic model, and again we'll map that
through to whatever QEMU provides. So apps using libvirt don't worry 
about what QEMU's exact naming scheme is for processors, but rather use
libvirt's database of defined names which are mapped to QEMUs.  Now for
convenience our database happens to match the QEMU database exactly at
this time :-) Finally we also use the same CPU model databse to expose
what the host CPU is, and provide APIs to allow apps to query whether a
desired guest model is compatible with the current host CPU model

The reason for libvirt doing it in this way, is that we wanted to have
apps use CPU model names primarily, but with option to override flags if
they needed. For the Xen and VMWare drivers the CPU model names are in
fact changed into CPUID masks, since that's all those two HVs accept.

This is all a very long way of saying that mgmt apps based on libvirt
won't care about model names exposed in /proc/cpuinfo so there's no
particular need to have a direct mapping from them to QEMU for libvirt's

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]