From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L0piW-0003Kz-OE for qemu-devel@nongnu.org; Thu, 13 Nov 2008 22:51:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L0piU-0003Kl-Cr for qemu-devel@nongnu.org; Thu, 13 Nov 2008 22:51:31 -0500 Received: from [199.232.76.173] (port=39515 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0piU-0003Ki-6P for qemu-devel@nongnu.org; Thu, 13 Nov 2008 22:51:30 -0500 Received: from mail2.shareable.org ([80.68.89.115]:51735) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L0piT-0000rF-M4 for qemu-devel@nongnu.org; Thu, 13 Nov 2008 22:51:29 -0500 Date: Fri, 14 Nov 2008 03:51:22 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH 0/5] Add "info capabilities" monitor command Message-ID: <20081114035122.GM2055@shareable.org> References: <1226594763-2304-1-git-send-email-markmc@redhat.com> <491CF04F.5020408@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <491CF04F.5020408@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Mark McLoughlin Anthony Liguori wrote: > This is important for > determining things like whether a migration target's QEMU instance is > compatible with the source. It might be enough to list the emulated CPU variants, or it might need to list the capabilities of the specific CPU in some detail. For example on x86, there are lots of partially independent capabilities, but on the other hand, after an OS has checked for a specific CPU id, you really want the target QEMU to present the same CPU id. > As a general piece of advise, I think where you are starting from is a > bit ambitious and far too open for bike shedding to be productive. You > may find it easier to start with something simpler, that has a real > practical utility to libvirt, and then building on that incrementally. I think the capability list is quite a good idea, and it may stimulate something on the config file front. If it's "wrong" the first time, well, there are other features in QEMU which have changed incompatibly between versions. Imho, there's no great harm in changing "info capability" output until it's right, provided the basic syntax unambiguously represents the QEMU version and capability text format version somehow. While we're at it, a section describing the monitor's capabilities so we don't have to parse the _monitor's_ "help" output.... Oh, there I go bike-shedding again :-) -- Jamie