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

From: "Daniel P. Berrange" <berrange@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: mimu@linux.vnet.ibm.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
	borntraeger@de.ibm.com, Igor Mammedov <imammedo@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jiri Denemark <jdenemar@redhat.com>,
	rth@twiddle.net, Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models
Date: Tue, 23 Jun 2015 17:53:13 +0100	[thread overview]
Message-ID: <20150623165313.GN30318@redhat.com> (raw)
In-Reply-To: <55898BF3.9050107@suse.de>

On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 18:25 schrieb Daniel P. Berrange:
> > Whether QEMU changed the CPU for existing machines, or only for new
> > machines is actually not the core problem. Even if we only changed
> > the CPU in new machines that would still be an unsatisfactory situation
> > because we want to be able to be able to access different versions of
> > the CPU without the machine type changing, and access different versions
> > of the machine type, without the CPU changing. IOW it is the fact that the
> > changes in CPU are tied to changes in machine type that is the core
> > problem.
> 
> This coupling is by design and we expect all KVM/QEMU users to adhere to
> it, including those that use the libvirt tool (which I assume is going
> to be the majority of KVM users). Either you want a certain
> backwards-compatible machine and CPU, or you want the latest and
> greatest - why in the world mix and match?!

As mentioned, changes/fixes to the CPU model can affect the ability to
launch the guest on a particular host, so we need the ability to control
when those CPU changes are activated for a guest, separately from the
machine type.

> Would a qemu64-2.3 model help here that pc*-2.3 could use? I believe
> that's been proposed in the past. I don't oppose the idea of a
> fully-custom CPU, but this blatant attempt of ignoring QEMU's CPU
> versioning by libvirt worries me.

That is still tieing CPU model names to machine type versions, unless
I'm mis-understanding you. In general having QEMU models avialable
vary depending on the QEMU version is creating problems for apps
higher up the stack. By allowing libvirt to define the CPU model
policy, it can also provide a more consistent interface to applications
above, such as OpenStack, which will facilitate work in the schedular
when it picks hosts capable of deploying/migrating a VM, when there
are heterogenous QEMU versions across the hosts.

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