From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SXH-0007EM-1J for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:03:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7SXC-00043X-RM for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:03:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SXC-00043M-Mz for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:02:58 -0400 Date: Tue, 23 Jun 2015 18:55:21 +0100 From: "Daniel P. Berrange" Message-ID: <20150623175521.GR30318@redhat.com> References: <20150623155832.GE3134@thinpad.lan.raisama.net> <55898637.6080804@suse.de> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55899A5E.3060509@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:41:50PM +0200, Andreas F=C3=A4rber wrote: > Only if you use "-cpu ...,enforce", no? >=20 > The KVM feature filtering should take care of dropping features that ar= e > not available otherwise. >=20 > So we seem to be getting to the interesting case of the same machine > (different from what was said previously!) but different hosts. >=20 > The QOM property gives you insights into which feature bits are set for > the machine for the model (and for s390x I saw QMP extensions to the > same effect, I thought). That way you could discover features to > disable. However you'll only ever know which ones work once you've trie= d > it once, right? On this subject, a big problem in QOM in general is that it hasn't included a distinction between object classes and object instances. So there's no way for us to introspect what a machine type provides without actually instantiating a guest with that machine type. Again allowing libvirt to control the CPU model removes this problem as libvirt will be able to determine what CPUs it can run on a given host without having to probe all the different CPU <-> machine type combinations for the QEMU on that host has. This in turn simplifies life for apps using libvirt, as they will always know that "CPUFoo-X.Y" will always mean the exact same thing on all the hosts they have no matter what QEMU version/machine is in use. 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 :|