From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NY1Fq-00061E-No for qemu-devel@nongnu.org; Thu, 21 Jan 2010 12:55:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NY1Fl-0005uL-MX for qemu-devel@nongnu.org; Thu, 21 Jan 2010 12:55:38 -0500 Received: from [199.232.76.173] (port=60576 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NY1Fl-0005u4-HL for qemu-devel@nongnu.org; Thu, 21 Jan 2010 12:55:33 -0500 Received: from mail2.shareable.org ([80.68.89.115]:43560) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NY1Fl-0000vq-1b for qemu-devel@nongnu.org; Thu, 21 Jan 2010 12:55:33 -0500 Date: Thu, 21 Jan 2010 17:55:30 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. Message-ID: <20100121175530.GB28467@shareable.org> References: <4B549016.6090501@redhat.com> <20100119221548.GC11920@shareable.org> <4B57638A.1060103@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B57638A.1060103@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: john cooper Cc: "Przywara, Andre" , qemu-devel@nongnu.org, KVM list john cooper wrote: > > I foresee wanting to iterate over the models and pick the latest one > > which a host supports - on the grounds that you have done the hard > > work of ensuring it is a reasonably good performer, while "probably" > > working on another host of similar capability when a new host is made > > available. > > That's a fairly close use case to that of safe migration > which was one of the primary motivations to identify > the models being discussed. Although presentation and > administration of such was considered the domain of management > tools. My hypothetical script which iterates over models in that way is a "management tool", and would use qemu to help do its job. Do you mean that more powerful management tools to support safe migration will maintain _their own_ processor model tables, and perform their calculations using their own tables instead of querying qemu, and therefore not have any need of qemu's built in table? If so, I favour more strongly Anthony's suggestion that the processor model table lives in a config file (eventually), as that file could be shared between management tools and qemu itself without duplication. -- Jamie