From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SaI-0008TA-4F for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:06:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7SaE-0005JV-D4 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:06:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SaE-0005JP-74 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:06:06 -0400 Date: Tue, 23 Jun 2015 19:05:59 +0100 From: "Daniel P. Berrange" Message-ID: <20150623180559.GT30318@redhat.com> References: <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> <20150623172750.GP30318@redhat.com> <55899A5E.3060509@suse.de> <20150623174520.GM3134@thinpad.lan.raisama.net> <55899E54.3040403@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55899E54.3040403@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= 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 On Tue, Jun 23, 2015 at 07:58:44PM +0200, Andreas F=C3=A4rber wrote: > Am 23.06.2015 um 19:45 schrieb Eduardo Habkost: > > On Tue, Jun 23, 2015 at 07:41:50PM +0200, Andreas F=C3=A4rber wrote: > > [...] > >> If that is the whole problem here, then why not just add a global fl= ag > >> to only enable explicitly requested KVM features? All other features > >> should not depend on the host, and the whole discussion about -x.y s= eems > >> like a distraction. > >=20 > > Now replace "KVM features" with "CPU fatures", because all CPU featur= es > > are KVM features, as all of them depend on KVM code enabling them on > > GET_SUPPORTED_CPUID. > >=20 > > Thus, the global flag to only enable explicitly request KVM features = on > > CPUs is "-cpu custom", which doesn't enable any CPU feature at all. >=20 > If libvirt wants to use an empty CPU model, then why export our models > to libvirt? >=20 > I don't mind there being an optional custom model, I mind our > compat_props getting ignored that way, which are unrelated to adding ne= w > features, in fact they suppress just that for the -2.3 examples. If QEMU has a '-cpu custom' there isn't actually any need for QEMU to export its CPU models to libvirt. Libvirt already has its own CPU model database, so we'd just start to use our own database exclusively. Libvirt would have to take care that we don't break ABI when updating from a QEMU that pre-dates the '-cpu custom' feature - for that we have done a one-time only extraction of details of all the historical variations in QEMU CPUS models per machine type. So apart from backcompat for existing QEMUs in the wild, libvirt would no longer have any need to know about QEMU's CPU models. Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|