qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt
Date: Sat, 10 Mar 2012 12:42:46 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Mar 09, 2012 at 09:04:03PM +0000, Daniel P. Berrange wrote:
> On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote:
> > Resurrecting an old thread:
> > 
> > I didn't see any clear conclusion in this thread (this is why I am
> > resurrecting it), except that many were arguing that libvirt should
> > simply copy and/or generate the CPU model definitions from Qemu. I
> > really don't think it's reasonable to expect that.
> > 
> > On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote:
> > > Hi,
> > > 
> > > Recently I realized that all modern CPU models defined in
> > > /etc/qemu/target-x86_64.conf are useless when qemu is used through 
> > > libvirt.
> > > That's because we start qemu with -nodefconfig which results in qemu 
> > > ignoring
> > > that file with CPU model definitions. We have a very good reason for using
> > > -nodefconfig because we need to control the ABI presented to a guest OS 
> > > and we
> > > don't want any configuration file that can contain lots of things 
> > > including
> > > device definitions to be read by qemu. However, we would really like the 
> > > new
> > > CPU models to be understood by qemu even if used through libvirt. What 
> > > would
> > > be the best way to solve this?
> > > 
> > > I suspect this could have been already discussed in the past but 
> > > obviously a
> > > workable solution was either not found or just not implemented.
> > 
> > So, our problem today is basically:
> > 
> > A) libvirt uses -nodefconfig;
> > B) -nodefconfig makes Qemu not load the config file containing the CPU
> >    model definitions; and
> > C) libvirt expects the full CPU model list from Qemu to be available.
> 
> I could have sworn we had this discussion a year ago or so, and had decided
> that the default CPU models would be in something like 
> /usr/share/qemu/cpu-x86_64.conf
> and loaded regardless of the -nodefconfig setting. 
> /etc/qemu/target-x86_64.conf
> would be solely for end user configuration changes, not for QEMU builtin
> defaults.
> 
> But looking at the code in QEMU, it doesn't seem we ever implemented this ?

Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs but,
contrary to our normal RHEL development practice, it was not based on
a cherry-pick of an upstream patch :-(

For sake of reference, I'm attaching the two patches from the RHEL6 source
RPM that do what I'm describing

NB, I'm not neccessarily advocating these patches for upstream. I still
maintain that libvirt should write out a config file containing the
exact CPU model description it desires and specify that with -readconfig.
The end result would be identical from QEMU's POV and it would avoid
playing games with QEMU's config loading code.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Attachment: kvm-Move-CPU-definitions-to-usr-share-.-BZ-610805.patch
Description: Text document

Attachment: kvm-Bug-625333-qemu-treatment-of-nodefconfig-and-readcon.patch
Description: Text document


reply via email to

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