From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9EHq-0007Ip-T8 for qemu-devel@nongnu.org; Wed, 16 Dec 2015 10:46:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9EHn-0005lV-Et for qemu-devel@nongnu.org; Wed, 16 Dec 2015 10:46:42 -0500 Received: from mx2.suse.de ([195.135.220.15]:35040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9EHn-0005lP-7o for qemu-devel@nongnu.org; Wed, 16 Dec 2015 10:46:39 -0500 References: <1449728144-6223-1-git-send-email-bharata@linux.vnet.ibm.com> <20151210133505.22b303c7@igors-macbook-pro.local> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <5671875D.8030405@suse.de> Date: Wed, 16 Dec 2015 16:46:37 +0100 MIME-Version: 1.0 In-Reply-To: <20151210133505.22b303c7@igors-macbook-pro.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov , Bharata B Rao Cc: peter.maydell@linaro.org, ehabkost@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, pbonzini@redhat.com, david@gibson.dropbear.id.au Am 10.12.2015 um 13:35 schrieb Igor Mammedov: > wrt CLI can't we do something like this? >=20 > -device some-cpu-model,socket=3Dx[,core=3Dy[,thread=3Dz]] That's problematic and where my x86 remodeling got stuck. It works fine (more or less) to model sockets, cores and hyperthreads for -smp, but doing it dynamically did not work well. How do you determine the instance size a socket with N cores and M threads needs? Allocations in instance_init are to be avoided with a view to hot-plug. So either we have a fully determined socket object or we need to wire individual objects on the command line. The latter has bad implications for atomicity and thus hot-unplug. That leaves us with dynamic properties doing allocations and reporting it via Error**, something I never finished and could use reviewers and contributors. Anthony's old suggestion had been to use real socket product names like Xeon-E5-4242 to get a 6-core, dual-thread socket, without parameters - unfortunately I still don't see an easy way to define such a thing today with the flexibility users will undoubtedly want. And since the question came up how to detect this, what you guys seem to keep forgetting is that somewhere there also needs to be a matching link<> property that determines what can be plugged, i.e. QMP qom-list. link<>s are the QOM equivalent to qdev's buses. The object itself needs to live in /machine/peripheral or /machine/peripheral-anon (/machine/unattached is supposed to go away after the QOM conversion is done!) and in a machine-specific place there will be a /machine/cpu-socket[0] -> /machine/peripheral-anon/device[42] link property. It might just as well be /machine/daughterboard-x/cpu-core[2] -> /machine/peripheral/cpu0. (Gentle reminder of the s390 ipi modeling discussion that never came to any conclusion iirc.) Note that I have not read this patch series yet, just some of the alarming review comments. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N=FC= rnberg)