From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7S2U-0007SO-2U for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:31:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7S2P-0005r4-Lw for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:31:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7S2P-0005qV-Fb for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:31:09 -0400 Date: Tue, 23 Jun 2015 18:31:04 +0100 From: "Daniel P. Berrange" Message-ID: <20150623173104.GQ30318@redhat.com> References: <558951C0.3050806@suse.de> <20150623150828.GD3134@thinpad.lan.raisama.net> <20150623173048-mutt-send-email-mst@redhat.com> <20150623155832.GE3134@thinpad.lan.raisama.net> <55898637.6080804@suse.de> <20150623162555.GL30318@redhat.com> <55898BF3.9050107@suse.de> <20150623165313.GN30318@redhat.com> <558992F3.1060707@suse.de> <20150623172416.GJ3134@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150623172416.GJ3134@thinpad.lan.raisama.net> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: mimu@linux.vnet.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , Andreas =?utf-8?Q?F=C3=A4rber?= , rth@twiddle.net On Tue, Jun 23, 2015 at 02:24:16PM -0300, Eduardo Habkost wrote: > On Tue, Jun 23, 2015 at 07:10:11PM +0200, Andreas F=C3=A4rber wrote: > > Am 23.06.2015 um 18:53 schrieb Daniel P. Berrange: > > > On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas F=C3=A4rber wrote= : > > >> Am 23.06.2015 um 18:25 schrieb Daniel P. Berrange: > > >>> Whether QEMU changed the CPU for existing machines, or only for n= ew > > >>> machines is actually not the core problem. Even if we only change= d > > >>> the CPU in new machines that would still be an unsatisfactory sit= uation > > >>> because we want to be able to be able to access different version= s of > > >>> the CPU without the machine type changing, and access different v= ersions > > >>> 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 co= re > > >>> problem. > > >> > > >> This coupling is by design and we expect all KVM/QEMU users to adh= ere to > > >> it, including those that use the libvirt tool (which I assume is g= oing > > >> 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?! > > >=20 > > > 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 co= ntrol > > > when those CPU changes are activated for a guest, separately from t= he > > > machine type. > >=20 > > Why? Today's libvirt with QEMU 2.3 resolves "pc" machine to > > "pc-i440fx-2.3" and the guest XML stays that way. When we add new > > features for 2.4, 2.3 is guaranteed to stay compatible. Any change wo= uld > > involve the libvirt user actively switching from pc-i440fx-2.3 to a > > different machine such as upcoming pc-i440fx-2.4. Why do you need to > > change the CPU separately? Why would a user want to run 2.2's CPU wit= h a > > 2.3 machine? Or a 2.3 machine with a 2.4 CPU? That's nonsense. If you > > want to tweak features, you already have command line options availab= le > > to do so on the basis of what the selected machine provides. >=20 > Because pure guest-side ABI changes are different from changes that als= o > have additional host-side requirements, so we want to untie both things= . >=20 > About being able to tweak features today, that's true: we have > command-line options for most stuff and that's _almost_ enough for what > libvirt needs. What's missing is something to avoid silently getting ne= w > features that libvirt aren't aware of (but may make the VM unrunnable). > The purpose of "-cpu custom" is to ensure no new host side feature > requirement will be introduced silently, even if choosing a different > machine. It also has a positive impact on maintenance. By allowing libvirt to control the CPU definitions, in cases where there is a need to push out a CPU model bugfix, libvirt will often be able to make the update available to users via a new CPU model version, without them having to do a lock-step upgrade to QEMU at the same time. Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|