From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2MIY-0008PD-Gn for qemu-devel@nongnu.org; Thu, 25 Jul 2013 10:13:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2MIW-0004IG-KK for qemu-devel@nongnu.org; Thu, 25 Jul 2013 10:13:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2MIW-0004I2-Bj for qemu-devel@nongnu.org; Thu, 25 Jul 2013 10:13:40 -0400 Date: Thu, 25 Jul 2013 15:13:35 +0100 From: "Daniel P. Berrange" Message-ID: <20130725141334.GZ7382@redhat.com> References: <00920fe1cd728db02fa4c81602b359986a3cf2a1.1374595782.git.jdenemar@redhat.com> <20130723163242.GQ2477@redhat.com> <20130723172838.GJ4718@orkuz.home> <20130723173246.GK4718@orkuz.home> <20130724182519.GB3573@otherpad.lan.raisama.net> <51F0EC68.1020808@suse.de> <20130725140044.GA2714@otherpad.lan.raisama.net> <51F1318E.5000801@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51F1318E.5000801@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [libvirt] [PATCH 4/7] qemu: Add monitor APIs to fetch CPUID data from QEMU 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: libvir-list@redhat.com, Paolo Bonzini , Eduardo Habkost , Anthony Liguori , qemu-devel@nongnu.org On Thu, Jul 25, 2013 at 04:09:18PM +0200, Andreas F=C3=A4rber wrote: > Am 25.07.2013 16:00, schrieb Eduardo Habkost: > > libvirt > > needs a way to find out how exactly "-machine foo-1.0 -cpu bar" looks > > different from "-machine foo-1.1 -cpu bar", >=20 > Why? (What's the actual use case?) It already takes a long time to just probe each QEMU binary, without expanding that to probe each binary once for each machine type they include. The idea of 'qemu -M none' was that we'd have a machine type which did not do any hardware set, to query any aspect of the QEMU binary capabilities. If we have to also invoke qemu again with every other machine type that is a failed design IMHO. It should not be beyond the realm of possibility to make 'qemu -M none' provide information about the CPU features for machines/cpus without needing to actually creating instances of those machines. 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 :|