From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7T3A-0007qs-P2 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:36:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7T35-00038a-Le for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:36:00 -0400 Received: from cantor2.suse.de ([195.135.220.15]:41836 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7T35-00038L-5K for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:35:55 -0400 Message-ID: <5589A70A.9050201@suse.de> Date: Tue, 23 Jun 2015 20:35:54 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= 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> <20150623173917.GK3134@thinpad.lan.raisama.net> In-Reply-To: <20150623173917.GK3134@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 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: 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 , rth@twiddle.net Am 23.06.2015 um 19:39 schrieb Eduardo Habkost: > On Tue, Jun 23, 2015 at 07:18:06PM +0200, Andreas F=E4rber wrote: >> Am 23.06.2015 um 19:08 schrieb Eduardo Habkost: >>> On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas F=E4rber 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! >=20 > I am just talking about a different problem, and I don't know if you ar= e > purposely trying to ignore it, or are just denying that it is a problem= . So, are you and Dan talking about the same problem or different ones? I am not deliberately ignoring anything here, but I am denying there is a problem until either of you explains what a concrete problem is. Seems we are slowly getting there now. >> 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. >=20 > If you didn't change the machine name, this is not the problem we are > talking about. OK. >> 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. >=20 > If you didn't change the machine name, this is not the problem we are > talking about. >=20 >> >> 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 > Let's try a concrete example: >=20 > * User is running a kernel that can't emulate x2apic > * User is running pc-i440fx-1.7 > * User wants the gigabyte alignment change implemented by commit > bb43d3839c29b17a2f5c122114cd4ca978065a18 > * User changes machine to pc-i440fx-2.0 > * x2apic is now enabled by default in all CPU models > * VM with the same configuration (just the machine change) is not > runnable anymore in the same host Then let's take a step back: In order to change the machine type, the user shuts the machine down (it does not run!), edits the XML and tries to boot it up again. That's where I've challenged your use of the term of changed "runnability" above. I acknowledged, it might happen that it does not run. But that has nothing to do with compatibility of QEMU versions v2.3.0 vs. v2.4.0 then, it is the user's active choice of options that are incompatible with her system and that never before worked there. That seems perfectly valid and unavoidable, just like adding a non-existing command-line option or an unknown XML element to the guest config. The difference of opinion seems to be that when there is a bug in QEMU, I require that the user updates QEMU (not necessarily to a new version), whereas you are proposing that libvirt should be the one to work around bugs in QEMU by tweaking command line parameters. In order to get a virtio-scsi or gigabyte alignment fix that varies across -x.y machines, that feature can just as well be enabled via global properties on the old machine. New machines are primarily for new features. If someone wants to use that new -2.0 machine, they need to pass the correct options such as ",-x2apic" in your example or use a CPU model that does not enable such options by default. (FWIW in that concrete example I remember Paolo(?) saying that that feature had been supported for a really long time already.) The user, who actively edited the guest definition, gets an error message and has to edit the guest again and then it starts. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)