2:56 p.m.
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.
Those three expectations can't be fulfilled at the same time. So, we
have to break one of the expectations above. That means:
- Breaking (A), that would mean libvirt wouldn't use -nodefconfig. I
think -nodefconfig _has_ a point, even if it doesn't do much today, so
I think we can drop this possibility.
- Breaking (B), that means loading the CPU model definitions anyway
when using -nodefconfig.
I am inclined for this option: the list of CPU model defs are a list
of CPU "templates", not actual virtual machine configuration. The fact
that the CPU templates are stored in an external file instead of
hardcoded inside the Qemu source code is just an implementation
detail. A more detailed explanation is below.
- Breaking (C), that means libvirt would simply not have the existing
CPU model definitions available for its use. This is what happens
today.
The problem with this solution is: if we are spending lots of efforts
defining properly all those CPU definition templates, we should allow
the upper layers to reuse them, instead of forcing them to duplicate
work and maintain their own copies and deal with exactly the same
problems we had to deal inside Qemu.
This is related to the argument that "CPU definitions are part of
machine-types". Machine-types are a mechanism to allow new guest-visible
features to be added to a virtual machine without waiting until libvirt
can handle the details of that feature. You just choose a newer
machine-type, and the new features are going to be enabled, even if
libvirt doesn't know anything about it.
When libvirt starts to model some details of some feature, we can let it
probe for them, so it knows what's exactly being exposed to a guest.
But while these details are not modelled by libvirt, the only way we can
let the user enjoy new features as they are available is using
machine-types. And to make this work, machine-types details can't be
disabled using -nodefconfig.
Complementing what Gleb said at that time:
On Sun, Dec 18, 2011 at 11:58:16AM +0200, Gleb Natapov wrote:
> Ideally libvirt would just write out a config file with the CPU
> that was configured in libvirt and pass -readconfig
/var/lib/libvirt/qemu/guestcpu.conf
> That way libvirt can configure CPU models without regard for
> what the particular QEMU version might have in its config.
>
And how libvirt would know that particular QEMU/kvm version can create
this CPU. Managing cpuid shouldn't be libvirt busyness.
Even if managing CPUID bits is libvirt business on some specific cases,
this is not true for _all_ CPU details.
I don't think that the libvirt internal model of CPU features will be
ever complete (and maybe it even shouldn't be). There will be always
some feature that libvirt don't know anything about, and _that_ is what
we have to model inside the Qemu CPU definitions and/or inside
machine-type definitions--I don't think we even have a choice.
We can make it easier to change and probe for the existing CPU
definitions and features, in case libvirt wants to deal with some
details, but we can't expect libvirt to be able to configure every
single detail about the CPU.
--
Eduardo