From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSWH1-0001iI-Dk for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:50:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSWGw-0001hk-Ng for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:50:06 -0500 Received: from [199.232.76.173] (port=54430 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSWGw-0001hd-Gr for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:50:02 -0500 Received: from mail-yw0-f176.google.com ([209.85.211.176]:33129) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSWGv-0000qC-T7 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:50:02 -0500 Received: by ywh6 with SMTP id 6so17417780ywh.4 for ; Wed, 06 Jan 2010 05:49:50 -0800 (PST) Message-ID: <4B4494FC.1080907@codemonkey.ws> Date: Wed, 06 Jan 2010 07:49:48 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <4B2DF334.6030208@redhat.com> <20091220155101.GB31257@redhat.com> <4B2E49E5.6050709@redhat.com> <20091220165612.GC31257@redhat.com> <20091220171822.GD31257@redhat.com> <20091220172341.GB21163@redhat.com> <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> <4B449467.4070606@redhat.com> In-Reply-To: <4B449467.4070606@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Gleb Natapov , "Michael S. Tsirkin" , John Cooper , dlaor@redhat.com, qemu-devel@nongnu.org, Alexander Graf On 01/06/2010 07:47 AM, Avi Kivity wrote: > On 01/06/2010 03:25 PM, 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? > > Well, it's nice to have a -cpu X1234, so I wouldn't recommend dropping > it, but certainly a migration pool that doesn't assume anything about > the host qemu and kernel version needs more fine-grained information. > >> >> 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? > > -> { command: query-cpu-capabalities } > <- { result: { features: [vm, fpu, lm, sse2, sse3, sssse3, ssssssse3, > sse3.14 ], cache: { ... }, vendor: { .... }, etc. } } > > Or something. We'd need similar queries for the number of PCI slots, > for example, so the GUI can tell the user when adding hardware is no > longer an option instead of trying it blindly and returning an error. Yeah, the trick with this is that we don't have such a thing as a bare bones CPU in qemu right now. So you can't really say -cpu qemu64+vm+fpu+lm.... Because some extra features might sneak in. What I'm getting at is that we need a way to make the results of this command translate into a -cpu invocation that works reliably across multiple versions of qemu. Regards, Anthony Liguori