From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSW5n-0000SD-F3 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:38:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSW5i-0000Ng-Gf for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:38:31 -0500 Received: from [199.232.76.173] (port=33409 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSW5i-0000NT-B6 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:38:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17345) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSW5h-0005Sw-Od for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:38:26 -0500 Date: Wed, 6 Jan 2010 15:35:27 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm Message-ID: <20100106133527.GD2248@redhat.com> References: <2162E312-0110-42E1-A391-D75A6F013554@suse.de> <20091220173702.GC21163@redhat.com> <4B2E660F.1050703@codemonkey.ws> <20091221074355.GU4490@redhat.com> <4B2F31B1.6040403@redhat.com> <4B30EFDF.4060202@codemonkey.ws> <4B31F1BA.10005@redhat.com> <4B43D4E2.9050102@codemonkey.ws> <4B4402B1.1030605@redhat.com> <4B448F36.8030605@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B448F36.8030605@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Gleb Natapov , John Cooper , dlaor@redhat.com, qemu-devel@nongnu.org, Alexander Graf , Avi Kivity On Wed, Jan 06, 2010 at 07:25:10AM -0600, Anthony Liguori wrote: > On 01/05/2010 09:25 PM, Avi Kivity wrote: >>> Typically, there is at least a little sanity naming for these cases. >>> For instance, any Xeon W35xx should have the same features. A Xeon >>> W55xx may be different. >>> >>> It's not going to be easy to include every possible model. It's a >>> hard problem for management tools too. The thing is, I imagine most >>> management tools are going to cat /proc/cpuinfo to get what the >>> processor is and that's going to be a Xeon YYXXXX type name so I >>> really believe that's the thing that makes sense to expose in QEMU. >>> >>> Maybe we could name models like IntelXeonW35xx. >>> >> >> While a W3501 should be similar to a W3599, we don't know if it >> actually will be. You are no longer on a Fully Correct path and >> instead you are wandering in Marketing Land. >> >> Note that the processor type is just part of what determines which >> features are exposed to the guest. Qemu version, kvm version, host >> kernel version, and even kernel command-line parameters all play a >> part, so to really determine migratability the management tool should >> talk to qemu, not /proc/cpuinfo. > > So if I understand correctly, you're advocating to drop the idea of > common model names, and provide a mechanism for a management tool to > query which cpu features are supported both by the processor, but also > filtered by qemu, kvm, etc? The syscall issue shows there are several other things necessary IMO: - features need to be scoped with Vendor ID as some feature bits might not be 100% compatible. - Some features might be emulated. So it's not yes/no but yes/no/slow and management needs to know IMO. > I think that's workable but I think there may be some subtle issues > especially across qemu versions. Can you give an example of what you > would expect the output to be? > >>> Clever use of the preprocessor will make this effort much, much saner. >> >> I cringe whenever I read something like this. > > :-) > > Regards, > > Anthony Liguori