From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7lU2-0001Iy-Ro for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:17:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7lTx-0000OT-I9 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:16:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7lTx-0000OF-8Z for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:16:53 -0400 Date: Wed, 24 Jun 2015 11:16:51 -0300 From: Eduardo Habkost Message-ID: <20150624141651.GS3134@thinpad.lan.raisama.net> References: <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> <20150623231818-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20150623231818-mutt-send-email-mst@redhat.com> 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: "Michael S. Tsirkin" Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , Andreas =?iso-8859-1?Q?F=E4rber?= , rth@twiddle.net On Tue, Jun 23, 2015 at 11:23:16PM +0200, Michael S. Tsirkin wrote: > On Tue, Jun 23, 2015 at 05:42:04PM +0100, Daniel P. Berrange wrote: > > 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=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 wr= ote: > > > > > >>> 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 is provided, > > > > > >>>>>> that will generate a config file that can be loaded usin= g -readconfig, based on > > > > > >>>>>> the -cpu and -machine options provided in the command-li= ne. > > > > > >>>>> > > > > > >>>>> Thanks Eduardo, I never was a big fan of moving (or copyi= ng) all the CPU > > > > > >>>>> configuration data to libvirt, but now I think it actuall= y makes sense. > > > > > >>>>> We already have a partial copy of CPU model definitions i= n libvirt > > > > > >>>>> anyway, but as QEMU changes some CPU models in some machi= ne types (and > > > > > >>>>> libvirt does not do that) we have no real control over th= e guest CPU > > > > > >>>>> configuration. While what we really want is full control = to enforce > > > > > >>>>> 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 -mmac= hine, not > > > > > >>> that the ABI is broken by a given machine. > > > > > >>> > > > > > >>> The problem here is that libvirt needs to provide CPU model= s whose > > > > > >>> runnability does not depend on the machine-type. If users h= ave a VM that > > > > > >>> is running in a host and the VM machine-type changes, > > > > > >> > > > > > >> How does it change, and why? > > > > > >=20 > > > > > > Sometimes we add features to a CPU model because they were no= t emulated by KVM > > > > > > and now they are. Sometimes we remove or add features or chan= ge 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. > > > > > >=20 > > > > > > See some examples at the end of this message. > > > > > >=20 > > > > > >> > > > > > >>> the VM should be > > > > > >>> still runnable in that host. QEMU doesn't provide that, our= CPU models > > > > > >>> may change when we introduce new machine-types, so we are g= iving them a > > > > > >>> mechanism that allows libvirt to implement the policy they = need. > > > > > >> > > > > > >> I don't mind wrt CPU specifically, but we absolutely do chan= ge guest ABI > > > > > >> in many ways when we change machine types. > > > > > >=20 > > > > > > All the other ABI changes we introduce in QEMU don't affect r= unnability of the > > > > > > VM in a given host, that's the problem we are trying to addre= ss here. ABI > > > > > > changes are expected when changing to a new machine, runnabil= ity changes > > > > > > aren't. > > > > > >=20 > > > > > >=20 > > > > > > Examples of commits changing CPU models: > > > > > [snip] > > > > >=20 > > > > > I've always advocated remaining backwards-compatible and only m= aking 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 a= rgument > > > > > to stop using QEMU's CPU models at all? That sounds convoluted.= .. > > > >=20 > > > > 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. > > >=20 > > > 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 allowin= g > > libvirt to fix the CPU bugs in a way that is independant of the machi= ne > > types and portable across hypervisors we deal with. We're absolutely > > still going to fix CPU model bugs and ensure stable guest ABI. > >=20 > > Regards, > > Daniel >=20 > So any single CPU flag now needs to be added in > - kvm > - qemu > - libvirt >=20 > Next thing libvirt will decide it's a policy thing and so > needs to be pushed up to openstack. I don't think that will happen, but if they really decide do do it, why should we try to stop them? libvirt and OpenStack know what their users do/need better than us, and if they believe moving data to OpenStack will provide what users need, they are free to do it. I trust libvirt developers to do the right thing, here. >=20 > We should just figure out what you want to do and support it in QEMU. >=20 > Are there many examples where a single flag used to work and then > stopped? I would say such a change is problematic anyway: > not everyone uses libvirt, you are breaking things for people > that run -M pc. People using -M pc have to live with the fact that the host-side requirements of -M pc may change in newer QEMU versions. (Again, this is not about ABI changes, but about adding new host-side hardware/kernel requirements to make a VM run) >=20 > IMHO -M pc is not supposed to mean "can break at any time". It means "it may have new host-side requirements and may become runnable in your host (or require additional command-line flags to run) at any tim= e". --=20 Eduardo