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

["Michael S. Tsirkin" <mst@redhat.com>]

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,

How does it change, and why?

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

I don't mind wrt CPU specifically, but we absolutely do change guest ABI
in many ways when we change machine types.

> -- 
> Eduardo