From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5Px7-0000bE-Qo for qemu-devel@nongnu.org; Wed, 07 Mar 2012 18:07:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5Pww-0007JI-G7 for qemu-devel@nongnu.org; Wed, 07 Mar 2012 18:07:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25870) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5Pww-0007J3-73 for qemu-devel@nongnu.org; Wed, 07 Mar 2012 18:07:14 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q27N7CDZ024948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Mar 2012 18:07:12 -0500 Message-ID: <4F57EA1A.9010009@redhat.com> Date: Wed, 07 Mar 2012 16:07:06 -0700 From: Eric Blake MIME-Version: 1.0 References: <20120306182752.GC2914@otherpad.lan.raisama.net> <20120307141828.GB27024@redhat.com> <20120307222624.GA30550@otherpad.lan.raisama.net> In-Reply-To: <20120307222624.GA30550@otherpad.lan.raisama.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig2D3C8B531057B839E02589DC" Subject: Re: [Qemu-devel] [libvirt] Qemu, libvirt, and CPU models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , libvir-list@redhat.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D3C8B531057B839E02589DC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/07/2012 03:26 PM, Eduardo Habkost wrote: > Thanks a lot for the explanations, Daniel. >=20 > Comments about specific items inline. >=20 >>> - How can we make sure there is no confusion between libvirt and Qe= mu >>> about the CPU models? For example, what if cpu_map.xml says model= >>> 'Moo' has the flag 'foo' enabled, but Qemu disagrees? How do we >>> guarantee that libvirt gets exactly what it expects from Qemu whe= n >>> it asks for a CPU model? We have "-cpu ?dump" today, but it's not= >>> the better interface we could have. Do you miss something in spec= ial >>> in the Qemu<->libvirt interface, to help on that? >=20 > So, it looks like either I am missing something on my tests or libvirt > is _not_ probing the Qemu CPU model definitions to make sure libvirt > gets all the features it expects. >=20 > Also, I would like to ask if you have suggestions to implement > the equivalent of "-cpu ?dump" in a more friendly and extensible way. > Would a QMP command be a good alternative? Would a command-line option > with json output be good enough? I'm not sure where we are are using "-cpu ?dump", but it sounds like we should be. >=20 > (Do we have any case of capability-querying being made using QMP before= > starting any actual VM, today?) Right now, we have two levels of queries - the 'qemu -help' and 'qemu -device ?' output is gathered up front (we really need to patch things to cache that, rather than repeating it for every VM start). Then we start qemu with -S, query QMP, all before starting the guest (qemu -S is in fact necessary for setting some options that cannot be set in the current CLI but can be set via the monitor) - but right now that is the only point where we query QMP capabilities. If QMP can alter the CPU model prior to the initial start of the guest, then that would be a sufficient interface. But I'm worried that once we start qemu, even with qemu -S, that it's too late to alter the CPU model in use by that guest, and that libvirt should instead start querying these things in advance. We definitely want a machine-parseable construct, so querying over QMP rather than '-cpu ?dump' sounds like it might be nicer, but it would also be more work to set up libvirt to do a dry-run query of QMP capabilities without also starting a real guest. >=20 > But what about the features that are not available on the host CPU, > libvirt will think it can't be enabled, but that _can_ be enabled? > x2apic seems to be the only case today, but we may have others in the > future. That's where having an interface to probe qemu to see what capabilities are possible for any given cpu model would be worthwhile, so that libvirt can correlate the feature sets properly. >=20 > That answers most of my questions about how libvirt would handle change= s > on CPU models. Now we need good mechanisms that allow libvirt to do > that. If you have specific requirements or suggestions in mind, please > let me know. I'll let others chime in with more responses, but I do appreciate you taking the time to coordinate this. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig2D3C8B531057B839E02589DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPV+oaAAoJEKeha0olJ0NqHM8H/1Tt8wqyDgIqfOAv+MtNs2p2 zg8a/MWm62LXZE5HW2b0SssRe139oMsRpJqzYg++zXJxX12mggaDUx6QyEuZSgds TrYrat4ER/73eLNJISlbVc9NFvCu5mG1t5GXyzIhZd8J4ZCNOfZVE0vRRlY41e40 aLeYAKEbuIaugxp2wyjgEDvC1rK5COAz2Y53RUEBLL+mwQNDuWnnhjP1mvSa8arI 9AGxtEEzpQK/Ptg6g0bqvylxTmrcfphVxnNyLDhldwQbbsgQvYlNWEICHHdFQnb6 DL+I2CpHmFWzPMYJd0wfDubXUAj/14jQjUNsfHzWyH+frjh/vyBijCXRqYza2jQ= =UYUo -----END PGP SIGNATURE----- --------------enig2D3C8B531057B839E02589DC--