From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG4cT-0003zR-81 for qemu-devel@nongnu.org; Mon, 04 Jan 2016 07:52:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG4cP-0004Kn-SJ for qemu-devel@nongnu.org; Mon, 04 Jan 2016 07:52:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG4cP-0004KJ-K7 for qemu-devel@nongnu.org; Mon, 04 Jan 2016 07:52:13 -0500 Date: Mon, 4 Jan 2016 13:52:08 +0100 From: Igor Mammedov Message-ID: <20160104135208.728f3133@nial.brq.redhat.com> In-Reply-To: <20160101034748.GA17152@in.ibm.com> References: <1449728144-6223-1-git-send-email-bharata@linux.vnet.ibm.com> <20151210133505.22b303c7@igors-macbook-pro.local> <5671875D.8030405@suse.de> <20160101034748.GA17152@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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: 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, Andreas =?UTF-8?B?RsOkcmJlcg==?= , david@gibson.dropbear.id.au On Fri, 1 Jan 2016 09:17:48 +0530 Bharata B Rao wrote: > On Wed, Dec 16, 2015 at 04:46:37PM +0100, Andreas F=C3=A4rber wrote: > > Am 10.12.2015 um 13:35 schrieb Igor Mammedov: =20 > > > wrt CLI can't we do something like this? > > >=20 > > > -device some-cpu-model,socket=3Dx[,core=3Dy[,thread=3Dz]] =20 > >=20 > > 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. > >=20 > > 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. > >=20 > > 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.) > >=20 > > Note that I have not read this patch series yet, just some of the > > alarming review comments. =20 >=20 > It has been more than an year since I posted the initial version of > PowerPC sPAPR CPU hotplug patchset. I guess x86 CPU hotplug patchset > existed even before that. Now we have patches for s390 CPU hotplug > also on the list. Given this situation, will it be agreeable and > feasible to follow Igor's suggestion and de-link the QOM part from the > actual CPU hotplug work ? May be we can get these patchsets into 2.6 and > work on QOM links subsequently ? how about doing it in 2 series in parallel, 1st: a target specific cpu hotplug 2nd: QMP interface that would suite management needs to enumerate existing/possible CPU objects at the granularity which targets support from -device/device_add aspect (i.e. focuses only on hotplug POV) > Regards, > Bharata. >=20 >=20