From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7lbi-0000WS-QV for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:24:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7lbc-00054h-QU for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:24:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7lbc-00054Z-MA for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:24:48 -0400 Date: Wed, 24 Jun 2015 11:24:46 -0300 From: Eduardo Habkost Message-ID: <20150624142446.GU3134@thinpad.lan.raisama.net> 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> <20150623164204.GM30318@redhat.com> <55898D94.4070702@suse.de> <20150623171122.GI3134@thinpad.lan.raisama.net> <20150623213445.GA17756@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150623213445.GA17756@redhat.com> 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:34:45PM +0200, Michael S. Tsirkin wrote: > On Tue, Jun 23, 2015 at 02:11:22PM -0300, Eduardo Habkost wrote: > > Even if it is a bug fix. If it is a change that can make the VM > > unrunnable, it needs to be controlled by a separate flag, not by the > > machine-type. > > I agree - command line compatibility is important. But we are supposed > to provide that. I am surprised that libvirt suddenly wants to avoid > some command line flags because they are not stable. IMHO we did something > wrong here if so. Maybe there was a valid reason for it. But then won't > it apply to libvirt as well? Maybe we are having the same misunderstanding here: the problem is not compatibility/stability of existing machines, but the kind of (intentional) changes introduced in _new_ machines (when the -machine argument is changed). There are two kinds of changes introduced in new machines: 1) Guest-side-only ABI changes: those are OK, libvirt normally ignore them, they can't make a VM not-runnable. 2) Changes in the host-side dependencies: those need to be more carefully controlled by libvirt. That's where CPU features are special: all CPU features depend KVM-side features, and enabling them by default on new machines makes it impossible for libvirt to know/report in advance what's necessary to make a VM runnable and to implement their existing runnability APIs[1]. Unless we guarantee that QEMU would never introduce type-(2) changes in new machines (which I don't think will ever happen because that means never changing existing CPU models in QEMU), libvirt needs to control CPU features individually (that's why they need -cpu custom). > > Now, if people want to update CPU models outside the QEMU binary, > that might be doable simply by moving them to a separate package, > with a text file that QEMU reads at startup. You seem to be describing exactly what is made possible by "-cpu custom -readconfig " [1] http://libvirt.org/html/libvirt-libvirt-host.html#virConnectCompareCPU (See the cover letter of this series) -- Eduardo