[libvirt] [PATCH v3] Support for cpu64-rhel* qemu cpu models

Jiri Denemark jdenemar at redhat.com
Mon Feb 13 14:32:26 UTC 2012


On Fri, Feb 10, 2012 at 11:22:09 -0700, Eric Blake wrote:
> On 01/30/2012 09:25 AM, Martin Kletzander wrote:
> > In qemu there are 2 cpu models (cpu64-rhel5 and cpu64-rhel6) not
> > supported by libvirt. This patch adds the support with the flags
> > specifications from /usr/share/qemu-kvm/cpu-model/cpu-x86_64.conf
> > ---
> > v3:
> >  - fixed sse3 naming (it's 'pni' in the features)
> > 
> > v2:
> >  - removed duplicated entries
> > 
> >  src/cpu/cpu_map.xml |   66 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 66 insertions(+), 0 deletions(-)
> 
> I'm assuming that you tested this (I did not spend the time meticulously
> cross-checking qemu with this list).  Upstream qemu does not provide
> these machine names; they are RHEL-specific.
> 
> Is it going to be an issue where we use libvirt on something like F16
> where qemu does not have these machine names?  Or is it okay for libvirt
> to have a larger list of machine names, to make out-of-box installation
> of newer libvirt onto older RHEL/CentOS machines just work with those
> new names?

It was designed to be okay. Libvirt checks what CPU models are supported by
qemu and avoids passing unsupported models to qemu. After all, we support
running libvirt with older releases of qemu (we don't force their git HEAD).

> Should this be a RHEL-specific patch for just the RHEL version of
> libvirt, rather than upstream?

I think having this patch in is better than the opposite :-) Allowing
RHEL/CentOS users to install newer libvirt without losing functionality is
nice and we already did so in the past:

    commit ff88cd590572277f10ecee4ebb1174d9b70fc0d7
    Author: Eric Blake <eblake at redhat.com>
    Date:   Wed Jan 25 21:33:21 2012 -0700

        qemu: support qmp on RHEL/CentOS qemu

Jirka




More information about the libvir-list mailing list