From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RZO-0004ZH-56 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:01:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7RZI-0008JS-7o for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:01:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37981 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RZH-0008J2-Mn for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:01:04 -0400 Message-ID: <558990CE.5020806@suse.de> Date: Tue, 23 Jun 2015 19:01:02 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= 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> <20150623163225.GF3134@thinpad.lan.raisama.net> In-Reply-To: <20150623163225.GF3134@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 18:32 schrieb Eduardo Habkost: > On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas F=E4rber 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=E4rber wrote: >>>>>> Am 08.06.2015 um 22:18 schrieb Jiri Denemark: >>>>>>>> To help libvirt in the transition, a x86-cpu-model-dump script i= s provided, >>>>>>>> that will generate a config file that can be loaded using -readc= onfig, based on >>>>>>>> the -cpu and -machine options provided in the command-line. >>>>>>> >>>>>>> Thanks Eduardo, I never was a big fan of moving (or copying) all = the CPU >>>>>>> configuration data to libvirt, but now I think it actually makes = sense. >>>>>>> We already have a partial copy of CPU model definitions in libvir= t >>>>>>> anyway, but as QEMU changes some CPU models in some machine types= (and >>>>>>> libvirt does not do that) we have no real control over the guest = CPU >>>>>>> configuration. While what we really want is full control to enfor= ce >>>>>>> stable guest ABI. >>>>>> >>>>>> That sounds like FUD to me. Any concrete data points where QEMU do= es not >>>>>> have a stable ABI for x86 CPUs? That's what we have the pc*-x.y ma= chines >>>>>> for. >>>>> >>>>> What Jiri is saying that the CPUs change depending on -mmachine, no= t >>>>> that the ABI is broken by a given machine. >>>>> >>>>> The problem here is that libvirt needs to provide CPU models whose >>>>> 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 emulat= ed by KVM >>> and now they are. Sometimes we remove or add features or change other= 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 decided= 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 mod= els >>>>> may change when we introduce new machine-types, so we are giving th= em a >>>>> mechanism that allows libvirt to implement the policy they need. >>>> >>>> I don't mind wrt CPU specifically, but we absolutely do change guest= ABI >>>> in many ways when we change machine types. >>> >>> All the other ABI changes we introduce in QEMU don't affect runnabili= ty of the >>> VM in a given host, that's the problem we are trying to address here.= ABI >>> changes are expected when changing to a new machine, runnability chan= ges >>> aren't. >>> >>> >>> Examples of commits changing CPU models: >> [snip] >> >> I've always advocated remaining backwards-compatible and only making C= PU >> model changes for new machines. You among others felt that was not >> always necessary, and now you're using the lack thereof as an argument >> to stop using QEMU's CPU models at all? That sounds convoluted... >> >=20 > Uh? I don't remember anybody suggesting changing CPU models on existing > machines. We always tried to keep existing machines compatible. Yes, we try in general. And in a few cases I was overruled, possibly related to TCG feature filtering or something. Thought that was the problem here - apparently not. Explanations seem to be the culprit here! >> BTW your list does not answer my question. You would need examples whe= re >> a CPU model changes between machines, and I am not aware of any exampl= e >> beyond the intentional -x.y variations. There are differences between >> KVM and TCG though, did you mean that? i440fx and q35 should be >> identical and isa-pc, too, and none anyway. None of this has anything = to >> do with the host CPU. >=20 > We are talking about the -x.y variations (that, yes, are intentional). > But the fact that CPU features change (even the intentional ones in the > -x.y machine variations) affect runnability of VMs (because enabling ne= w > CPU features in KVM require it to be supported by the host kernel code > and by the host CPU). >=20 > I was not thinking about the KVM and TCG differences, but this may also > help libvirt deal with the KVM and TCG differences if necessary. >=20 > I don't know what you mean by "i440fx and q35 should be identical" > above. In this thread there was a claim that CPU models varied between machine types. I am saying that there should be no CPU model differences between pc-i440fx-2.3 and pc-q35-2.3 etc. Thus the CPU model is not tied to one machine, but to the version of QEMU, with -x.y matching the corresponding release. No news to you, I would hope? 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)