From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SCp-0004Js-I3 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:41:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7SCm-0001zW-Ab for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:41:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:39693 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SCl-0001yy-VS for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:41:52 -0400 Message-ID: <55899A5E.3060509@suse.de> Date: Tue, 23 Jun 2015 19:41:50 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <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> <20150623183115-mutt-send-email-mst@redhat.com> <20150623163858.GG3134@thinpad.lan.raisama.net> <55898D09.2060405@suse.de> <20150623170859.GH3134@thinpad.lan.raisama.net> <558994CE.9050001@suse.de> <20150623172750.GP30318@redhat.com> In-Reply-To: <20150623172750.GP30318@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 19:27 schrieb Daniel P. Berrange: > On Tue, Jun 23, 2015 at 07:18:06PM +0200, Andreas F=C3=A4rber wrote: >> Am 23.06.2015 um 19:08 schrieb Eduardo Habkost: >>> On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas F=C3=A4rber wrote: >>>> Am 23.06.2015 um 18:38 schrieb Eduardo Habkost: >>>>> On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote: >>>>>> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote= : >>>>>>> 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. >>>>>> >>>>>> But that's because we are fixing bugs. If CPU X used to work on >>>>>> hardware Y in machine type A and stopped in machine type B, this i= s >>>>>> because we have determined that it's the right thing to do for the >>>>>> guests and the users. We don't break stuff just for fun. >>>>>> Why do you want to bring back the bugs we fixed? >>>>> >>>>> I didn't take the time to count them, but I bet most of the commits= I >>>>> listed on my previous e-mail message are not bug fixes, but new >>>>> features. >>>> >>>> Huh? Of course the latest machine model get new features. The point = is >>>> that the previous ones don't and that's what we are providing them f= or - >>>> libvirt is expected to choose one machine and the contract with QEMU= is >>>> that for that machine the CPU does *not* grow new features, and we'r= e >>>> going at great lengths to achieve that. So this thread feels more an= d >>>> more weird... >>> >>> We are not talking about changes to existing machines. We are talking >>> about having changes introduced in new machines (the one we did on >>> purpose) affecting the runnability of the VM. >> >> You are talking abstract! >> >> >> Example 1: >> >> Point A: Machine pc-i440fx-2.3 exists >> >> Runs or runs not. >> >> Point B: Machine pc-i440fx-2.3 still exists >> >> Still runs or runs not due to guest ABI stability rules. >> >> >> Example 2: >> >> Point A: pc-i440fx-2.4 does not exist in 2.3 >> >> Does not run becomes it doesn't exist. >> >> Point B: New pc-i440fx-2.4 >> >> Runs or does not run, and if so has more features than pc-i440fx-2.3. >> >> There is no runnability problem - either it runs or it doesn't, but >> there's no change over time. >> >> This is what the machine -x.y versioning is all about. >=20 > Consider a host currently running QEMU 2.3 with machine type > pc-i440fx-2.3 used with SandyBridge. >=20 > Now consider the def of SandyBridge was buggy and so in QEMU > 2.4 we add the missing CPU feature flag 'wizz', and only > enable that new feature flag with pc-i440fx-2.4 >=20 > Now consider there was a bug in the virtio-scsi driver that > we also fixed in QEMU 2.4 and thus pc-i440fx-2.4 includes > that fix. >=20 > Updating from pc-i440fx-2.3 to pc-i440fx-2.4 has a dependancy > on the host CPU including the 'wizz' flag that was added. This > new CPU feature can prevent the user from using the new machine > type to get the virtio-scsi bug fix. Thanks for this example! :) Only if you use "-cpu ...,enforce", no? The KVM feature filtering should take care of dropping features that are not available otherwise. So we seem to be getting to the interesting case of the same machine (different from what was said previously!) but different hosts. The QOM property gives you insights into which feature bits are set for the machine for the model (and for s390x I saw QMP extensions to the same effect, I thought). That way you could discover features to disable. However you'll only ever know which ones work once you've tried it once, right? I'm pretty sure that we've had discussions with Anthony and Avi on the same topic ages ago. Alex also made the -cpu best proposal long ago. In general, if you want to run on a group of hosts, then you need to figure out a common denominator - a CPU model name and optionally features to enable/disable. If that is the whole problem here, then why not just add a global flag to only enable explicitly requested KVM features? All other features should not depend on the host, and the whole discussion about -x.y seems like a distraction. Regards, Andreas > Separately versioning CPU models still lets us preserve a stable > guest ABI by default, but allows more flexibility when choosing > to opt out of the ABI for a particular upgrade. >=20 > Regards, > Daniel --=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)