Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models

[Daniel P. Berrange]

On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
> > Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> > >> To help libvirt in the transition, a x86-cpu-model-dump script is 
> > >> provided,
> > >> that will generate a config file that can be loaded using -readconfig, 
> > >> based on
> > >> the -cpu and -machine options provided in the command-line.
> > > 
> > > Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU
> > > configuration data to libvirt, but now I think it actually makes sense.
> > > We already have a partial copy of CPU model definitions in libvirt
> > > anyway, but as QEMU changes some CPU models in some machine types (and
> > > libvirt does not do that) we have no real control over the guest CPU
> > > configuration. While what we really want is full control to enforce
> > > stable guest ABI.
> > 
> > That sounds like FUD to me. Any concrete data points where QEMU does not
> > have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machines
> > for.
> 
> What Jiri is saying that the CPUs change depending on -mmachine, not
> that the ABI is broken by a given machine.
> 
> The problem here is that libvirt needs to provide CPU models whose
> runnability does not depend on the machine-type. If users have a VM that
> is running in a host and the VM machine-type changes, the VM should be
> still runnable in that host. QEMU doesn't provide that, our CPU models
> may change when we introduce new machine-types, so we are giving them a
> mechanism that allows libvirt to implement the policy they need.

Expanding on that, but tieing the CPU model to the machine type, QEMU
has in turn effectively tied the machine type to the host hardware.
eg, switching to a newer machine type, may then prevent the guest
from being able to launch on the hardware that it was previously
able to run on, due to some new requirement of the CPU model associated
with the machine type.

Libvirt wants the CPU models to be independant of the machine type,
so in general only the CPU model is dependant on hardware capabilities
and machine type is isolated from hardware.

Libvirt still intends to do versioning of the CPU models, but the
versioning will be separate from the versioning of the machine types,
and will be handled by libvirt itself.

This also allows us to get  further towards our goal which is to have a
consistent representation of CPU models across all libvirt hypervisors.
eg the same libvirt CPU model and versions can be made consistent across
kvm, xen, vmware, etc, as they're not longer changing behind our back
based on the qemu machine type.

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 :|