From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1IzO-0000YD-7u for qemu-devel@nongnu.org; Mon, 22 Jul 2013 12:29:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1IzJ-0004a9-U2 for qemu-devel@nongnu.org; Mon, 22 Jul 2013 12:29:34 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33762 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1IzJ-0004Zt-Jn for qemu-devel@nongnu.org; Mon, 22 Jul 2013 12:29:29 -0400 Message-ID: <51ED5DE5.5090704@suse.de> Date: Mon, 22 Jul 2013 18:29:25 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1374483382-12141-1-git-send-email-proljc@gmail.com> <1374483382-12141-5-git-send-email-proljc@gmail.com> <51ED0B7A.2010205@suse.de> <51ED14BD.8050406@suse.de> <51ED26AE.4030201@suse.de> <87li4ywr9s.fsf@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] -cpu behavior (was: [PATCH v3 4/4] target-openrisc: Fix cpu_model by name) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Christian Borntraeger , Richard Henderson , Jia Liu , Anthony Liguori , "qemu-devel@nongnu.org" Am 22.07.2013 17:38, schrieb Peter Maydell: > On 22 July 2013 16:25, Anthony Liguori wrote: >> Andreas F=C3=A4rber writes: >>> Am 22.07.2013 13:34, schrieb Peter Maydell: >>>> Looking at all of the '-cpu help' output, alpha seems to be >>>> the odd one out here: none of the others list valid CPUs >>>> with "-$arch-cpu" suffixes. >>> >>> Right, because all others had implemented -cpu ? before we introduced >>> that naming scheme and I tried to keep output compatibility for them. >>> Focus for alpha was therefore on -cpu foo compatibility only. >>> >>> Anthony had clearly stated on a KVM call that using full type names f= or >>> future CPU hot-add was the right thing to do and possibly even compos= ite >>> convenience types like 4core-xeonblabla-x86_64-cpu; how that relates = to >>> -cpu and new targets was never clearly defined though. ;) >> >> That's pretty gross, but yes, we should have: >> >> qemu -device Xeon-E5-4610,id=3Dsock0 -device Xeon-E5-4610,id=3Dsock1 >> >> Which effectively does: >> >> qemu -cpu SandyBridge -smp cores=3D6,threads=3D2,sockets=3D2 >> >> By today's standards. >=20 > That doesn't really answer the question of "should the argument > to -cpu be a QOM typename or a human friendly name?" though > (though I note none of your -cpu or -device argument examples > are QOM type names, since they're missing the -$arch-cpu suffix). Depending on how we register those types, they don't necessarily need an -$arch-cpu suffix iff they are deemed globally unique. In this case there would be a 32-bit and 64-bit type though, I guess. But there's no qemu executable either, so we shouldn't take the example literally. :P >> I think this applies equally well to other architecture. >> Model hardware more closely. >=20 > For ARM this would mean "don't support -cpu at all, it > is always hardwired by the board model" :-) No, it means the board creates the equivalent of -device tegra2-soc. :) Or exynos4210, highbank-soc or whatever. Less code in machine init, more code in QOM devices reusable with -M none -readconfig foo. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg