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 ?