From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RM3-00056R-1o for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:47:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7RLx-0001dH-9V for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:47:22 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37440 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RLw-0001dB-V8 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:47:17 -0400 Message-ID: <55898D94.4070702@suse.de> Date: Tue, 23 Jun 2015 18:47:16 +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> <20150623183115-mutt-send-email-mst@redhat.com> <20150623164204.GM30318@redhat.com> In-Reply-To: <20150623164204.GM30318@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:42 schrieb Daniel P. Berrange: > 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: >>> On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas F=C3=A4rber wrote: >>>> Am 23.06.2015 um 17:58 schrieb Eduardo Habkost: >>>>> On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote: >>>>>> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote: >>>>>>> On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas F=C3=A4rber wro= te: >>>>>>>> Am 08.06.2015 um 22:18 schrieb Jiri Denemark: >>>>>>>>>> To help libvirt in the transition, a x86-cpu-model-dump script= is provided, >>>>>>>>>> that will generate a config file that can be loaded using -rea= dconfig, based on >>>>>>>>>> the -cpu and -machine options provided in the command-line. >>>>>>>>> >>>>>>>>> Thanks Eduardo, I never was a big fan of moving (or copying) al= l the CPU >>>>>>>>> configuration data to libvirt, but now I think it actually make= s sense. >>>>>>>>> We already have a partial copy of CPU model definitions in libv= irt >>>>>>>>> anyway, but as QEMU changes some CPU models in some machine typ= es (and >>>>>>>>> libvirt does not do that) we have no real control over the gues= t CPU >>>>>>>>> configuration. While what we really want is full control to enf= orce >>>>>>>>> stable guest ABI. >>>>>>>> >>>>>>>> That sounds like FUD to me. Any concrete data points where QEMU = does not >>>>>>>> have a stable ABI for x86 CPUs? That's what we have the pc*-x.y = machines >>>>>>>> for. >>>>>>> >>>>>>> What Jiri is saying that the CPUs change depending on -mmachine, = not >>>>>>> that the ABI is broken by a given machine. >>>>>>> >>>>>>> The problem here is that libvirt needs to provide CPU models whos= e >>>>>>> runnability does not depend on the machine-type. If users have a = VM that >>>>>>> is running in a host and the VM machine-type changes, >>>>>> >>>>>> How does it change, and why? >>>>> >>>>> Sometimes we add features to a CPU model because they were not emul= ated by KVM >>>>> and now they are. Sometimes we remove or add features or change oth= er fields >>>>> because we are fixing previous mistakes. Recently we we were going = to remove >>>>> features from models because of an Intel CPU errata, but then decid= ed to create >>>>> a new CPU model name instead. >>>>> >>>>> See some examples at the end of this message. >>>>> >>>>>> >>>>>>> the VM should be >>>>>>> still runnable in that host. QEMU doesn't provide that, our CPU m= odels >>>>>>> may change when we introduce new machine-types, so we are giving = them a >>>>>>> mechanism that allows libvirt to implement the policy they need. >>>>>> >>>>>> I don't mind wrt CPU specifically, but we absolutely do change gue= st ABI >>>>>> in many ways when we change machine types. >>>>> >>>>> All the other ABI changes we introduce in QEMU don't affect runnabi= lity of the >>>>> VM in a given host, that's the problem we are trying to address her= e. ABI >>>>> changes are expected when changing to a new machine, runnability ch= anges >>>>> aren't. >>>>> >>>>> >>>>> Examples of commits changing CPU models: >>>> [snip] >>>> >>>> I've always advocated remaining backwards-compatible and only making= CPU >>>> model changes for new machines. You among others felt that was not >>>> always necessary, and now you're using the lack thereof as an argume= nt >>>> to stop using QEMU's CPU models at all? That sounds convoluted... >>> >>> 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. >> >> 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 is >> 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? >=20 > Huh, I never said we wanted to bring back bugs. This is about allowing > libvirt to fix the CPU bugs in a way that is independant of the machine > types and portable across hypervisors we deal with. We're absolutely > still going to fix CPU model bugs and ensure stable guest ABI. No, that's contradictory! Through the -x.y machines we leave bugs in the old models *exactly* to assure a stable guest ABI. Fixes are only be applied to new machines, thus I'm pointing out that you should not use a new CPU model with an old machine type. 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)