7:52 a.m.
On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
On 03/11/2012 08:27 AM, Gleb Natapov wrote:
>On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote:
>>Let's step back here.
>>
>>Why are you writing these patches? It's probably not because you
>>have a desire to say -cpu Westmere when you run QEMU on your laptop.
>>I'd wager to say that no human has ever done that or that if they
>>had, they did so by accident because they read documentation and
>>thought they had to.
No, it's because libvirt doesn't handle all the tiny small details
involved in specifying a CPU. All libvirty knows about are a set of CPU
flag bits, but it knows nothing about 'level', 'family', and
'xlevel',
but we would like to allow it to expose a Westmere-like CPU to the
guest.
libvirt does know how to use the Westmere CPU model today, if it is not
disabled by -nodefconfig. The interface it uses for probing has
deficiencies, but it works right now.
>>Humans probably do one of two things: 1) no cpu option or 2)
-cpu host.
>>
>And both are not optimal. Actually both are bad. First one because
>default cpu is very conservative and the second because there is no
>guaranty that guest will continue to work after qemu or kernel upgrade.
>
>Let me elaborate about the later. Suppose host CPU has kill_guest
>feature and at the time a guest was installed it was not implemented by
>kvm. Since it was not implemented by kvm it was not present in vcpu
>during installation and the guest didn't install "workaround
kill_guest"
>module. Now unsuspecting user upgrades the kernel and tries to restart
>the guest and fails. He writes angry letter to qemu-devel and is asked to
>reinstall his guest and move along.
-cpu best wouldn't solve this. You need a read/write configuration
file where QEMU probes the available CPU and records it to be used
for the lifetime of the VM.
If the CPU records are used for probing, this is yet another reason they
are not "configuration", but "defaults/templates to be used to build the
actual configuration".
IMHO, having to generate an opaque config file based on the results of
probing is poor interface design, for humans _and_ for machines. If we
have any bug on the probing, or on the data used as base for the
probing, or on the config generation, it will be impossible to deploy a
fix for the users.
This is why machine-types exist: you have the ability to implement
probing and/or sane defaults, but at the same time you can change the
probing behavior or the set of defaults without breaking existing
machines. This way, the config file contains only what the user really
wanted to configure, not some complex and opaque result of a probing
process.
Tthe fact that we have a _set_ of CPU definitions to choose from (or to
use as input for probing) instead of a single default "CPU" definition
that the user can change is a sign that that the cpudefs are _not_ user
configuration, but just templates/defaults.
[...]
This discussion isn't about whether QEMU should have a Westmere
processor definition. In fact, I think I already applied that patch.
It's a discussion about how we handle this up and down the stack.
Agreed on this point.
The question is who should define and manage CPU compatibility.
Right now QEMU does to a certain degree, libvirt discards this and
does it's own thing, and VDSM/ovirt-engine assume that we're
providing something and has built a UI around it.
libvirt doesn't discard this. If it just discarded this and properly
defined its own models, I wouldn't even have (re-)started this thread.
(Well, maybe I would have started a similar thread arguing that we are
wasting time working on equivalent known-to-work CPU model definitions
on Qemu and libvirt. Today we don't waste time doing it because libvirt
currently expects -nodefconfig to not disable the existing default
models).
What I'm proposing we consider: have VDSM manage CPU definitions in
order to provide a specific user experience in ovirt-engine.
I don't disagree completely with that. The problem is defining what's
"CPU definitions". The current cpudef semantics is simply too low level,
it impacts other features that are _already_ managed by Qemu. Let me try
to enumerate:
- Some CPUID leafs are defined based on -smp;
- Some CPUID leafs depend on kernel capabilities;
- The availability of some CPUID leafs depend on some features
being enabled or not, but they are simply not exposed if a proper
'level' value is set.
We could have two approaches here: we can define some details of CPU
definitions as "not configurable" and others as "must-be
configurable",
and force management layer to agree with us about what should be
configurable or not.
Or, we could simply define that a sane set of CPU definitions are part
of a machine-type, and let managment to reconfigure parts of it if
desired, but do not force it to configure it if not needed.
We would continue to have Westmere/etc in QEMU exposed as part of the
user configuration. But I don't think it makes a lot of sense to
have to modify QEMU any time a new CPU comes out.
Today we have to, because libvirt doesn't handle all the details of CPU
definitions. I would be happy if libvirt took to itself the
responsibility of defining all those CPUs, but that's not true today.
And even if we all agree that in the future libvirt will manage every
single detail of the CPU. I would still argue that CPU definition
defaults (especially if they are used as input for probing) should be
part of machine-type definitions, as not everybody uses libvirt.
--
Eduardo