From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RiB-0004yZ-OW for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:10:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7Ri9-0003k4-11 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:10:15 -0400 Received: from cantor2.suse.de ([195.135.220.15]:38417 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Ri8-0003j5-Hw for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:10:12 -0400 Message-ID: <558992F3.1060707@suse.de> Date: Tue, 23 Jun 2015 19:10:11 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1433790460-30679-1-git-send-email-ehabkost@redhat.com> <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> In-Reply-To: <20150623165313.GN30318@redhat.com> Content-Type: text/plain; charset=utf-8 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: "Daniel P. Berrange" 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, Eduardo Habkost 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 new >>> machines is actually not the core problem. Even if we only changed >>> the CPU in new machines that would still be an unsatisfactory situati= on >>> because we want to be able to be able to access different versions of >>> the CPU without the machine type changing, and access different versi= ons >>> of the machine type, without the CPU changing. IOW it is the fact tha= t 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?! >=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 contro= l > when those CPU changes are activated for a guest, separately from the > machine type. 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 would 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. >> 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. >=20 > 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. If you have heterogeneous QEMUs across hosts, then you need a common-denominator machine anyway because QEMU wouldn't start with a machine it doesn't know. Please give one concrete example of a real-world problem instead of hypothetical abstract combinations users may or may not be able to construct. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; = HRB 21284 (AG N=C3=BCrnberg)