From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NcOlP-0008Ew-K6 for qemu-devel@nongnu.org; Tue, 02 Feb 2010 14:50:19 -0500 Received: from [199.232.76.173] (port=36614 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NcOlO-0008Eo-OO for qemu-devel@nongnu.org; Tue, 02 Feb 2010 14:50:18 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NcOlM-0000yW-C0 for qemu-devel@nongnu.org; Tue, 02 Feb 2010 14:50:18 -0500 Received: from mx20.gnu.org ([199.232.41.8]:37097) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NcOlG-0000po-T1 for qemu-devel@nongnu.org; Tue, 02 Feb 2010 14:50:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NcOid-0000rY-7U for qemu-devel@nongnu.org; Tue, 02 Feb 2010 14:47:28 -0500 Message-ID: <4B687E5E.4060402@redhat.com> Date: Tue, 02 Feb 2010 14:34:54 -0500 From: john cooper MIME-Version: 1.0 References: <4B672535.5050303@redhat.com> <4B68075D.2030701@amd.com> In-Reply-To: <4B68075D.2030701@amd.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] Add cpu model configuration support.. (resend) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andre Przywara Cc: john.cooper@redhat.com, qemu-devel@nongnu.org, KVM list Andre Przywara wrote: >> +[cpudef] >> + name = "Conroe" >> + level = "2" >> + vendor = "GenuineIntel" >> + family = "6" >> + model = "2" >> + stepping = "3" >> + feature_edx = "sse2 sse fxsr mmx pat cmov pge sep apic cx8 mce pae >> msr tsc pse de fpu mtrr clflush mca pse36" >> + feature_ecx = "sse3 ssse3" >> + extfeature_edx = "fxsr mmx pat cmov pge apic cx8 mce pae msr tsc >> pse de fpu lm syscall nx" >> + extfeature_ecx = "lahf_lm" > Wouldn't it be much more user friendly to merge them all into one > string? Just from the feature names it is quite obscure to guess which > flag belongs into which string (especially since we lack the EXTn_ > prefix we had in helper.c). I haven't tried it, but the parsing code > looks like this shouldn't be too hard. > To avoid overlong lines one could think about a += operator. That's true. Although I expect setup of a cpu model to be a rather infrequent occurrence by the expert (+/-) user so the above didn't strike me as a significant issue. Also "-cpu ?cpuid" dumps out the entire motley crew of flags relative to each grouping for reference. That said the current config file syntax seems rather rigid and I think your suggestion makes sense. I avoided modifying the parser at this point just in the interest of minimizing the sprawl of this patch. > I would just drop all definitions here except qemu{32,64} and > kvm{32,64}. The other models should be described in the config file. That's the goal but I wanted to leave an interim firewall of sorts. If the target-x86_64.conf isn't installed for whatever reason, qemu still can fall back to the internal definitions. Even here it isn't strictly necessary to remove an internal def as it can be redefined in the config file which will override the internal version. In general -cpu "?model" will indicate internal vs. externally defined models by enclosing internal model names in brackets: : x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron) : x86 [athlon] QEMU Virtual CPU version 0.12.50 : It also seems worth dropping a hint to the user in the case qemu fails to find a target config file rather than leaving them to puzzle out why an external model has gone missing. Thanks for the feedback. -john -- john.cooper@redhat.com