From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Rvr-0008HK-49 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:24:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7Rvm-0002KK-RN for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:24:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Rvm-0002K9-JL for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:24:18 -0400 Date: Tue, 23 Jun 2015 14:24:16 -0300 From: Eduardo Habkost Message-ID: <20150623172416.GJ3134@thinpad.lan.raisama.net> References: <20150608201835.GM3525@orkuz.home> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <558992F3.1060707@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= 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 , rth@twiddle.net On Tue, Jun 23, 2015 at 07:10:11PM +0200, Andreas F=E4rber wrote: > Am 23.06.2015 um 18:53 schrieb Daniel P. Berrange: > > On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas F=E4rber 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 situa= tion > >>> because we want to be able to be able to access different versions = of > >>> the CPU without the machine type changing, and access different ver= sions > >>> of the machine type, without the CPU changing. IOW it is the fact t= hat 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 adher= e to > >> it, including those that use the libvirt tool (which I assume is goi= ng > >> 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 t= o > > launch the guest on a particular host, so we need the ability to cont= rol > > when those CPU changes are activated for a guest, separately from the > > 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 woul= d > 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 with = 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 available > to do so on the basis of what the selected machine provides. Because pure guest-side ABI changes are different from changes that also have additional host-side requirements, so we want to untie both things. 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 new 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. --=20 Eduardo