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

[Michael S. Tsirkin]

On Tue, Jun 23, 2015 at 05:00:54PM +0100, Daniel P. Berrange wrote:
> On Tue, Jun 23, 2015 at 05:56:35PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Jun 23, 2015 at 04:51:00PM +0100, Daniel P. Berrange wrote:
> > > 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.
> > 
> > So why not keep machine type stable?
> 
> There are many reasons to choose a particular machine type - for
> example, to achieve migration compat between hosts with different
> QEMU versions,

This might make you use an old machine type.
It will never make you use a newer machine type
so you will never run into problems.

> or to enable access to some performance or bug
> fix in the machine type in question.

Performance/bugfixes is exactly why we change these though.

> Users / apps need to be free
> to make those decisions, without being restricted by changes in the
> CPU model which may affect what hardware the machine type can be
> used on. The current use of machine types for CPU model versioning
> is placing users between a rock & hard place, giving them impossible
> decisions about which bad behaviour/bug they're willing to accept.
> 
> 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 :|