From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqAg6-0005ph-8N for qemu-devel@nongnu.org; Wed, 06 May 2015 21:32:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqAg3-0005zw-Pn for qemu-devel@nongnu.org; Wed, 06 May 2015 21:32:42 -0400 Date: Thu, 7 May 2015 11:06:51 +1000 From: David Gibson Message-ID: <20150507010651.GF1407@voom.redhat.com> References: <1429858066-12088-1-git-send-email-bharata@linux.vnet.ibm.com> <1429858066-12088-18-git-send-email-bharata@linux.vnet.ibm.com> <20150505072004.GO14090@voom.redhat.com> <20150506063757.GP18380@in.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iBwuxWUsK/REspAd" Content-Disposition: inline In-Reply-To: <20150506063757.GP18380@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v3 17/24] cpus: Reclaim vCPU objects List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: Zhu Guihua , mdroth@linux.vnet.ibm.com, aik@ozlabs.ru, agraf@suse.de, qemu-devel@nongnu.org, Chen Fan , qemu-ppc@nongnu.org, tyreld@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com, Gu Zheng , imammedo@redhat.com, afaerber@suse.de --iBwuxWUsK/REspAd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 06, 2015 at 12:07:57PM +0530, Bharata B Rao wrote: > On Tue, May 05, 2015 at 05:20:04PM +1000, David Gibson wrote: > > On Fri, Apr 24, 2015 at 12:17:39PM +0530, Bharata B Rao wrote: > > > From: Gu Zheng > > >=20 > > > In order to deal well with the kvm vcpus (which can not be removed wi= thout any > > > protection), we do not close KVM vcpu fd, just record and mark it as = stopped > > > into a list, so that we can reuse it for the appending cpu hot-add re= quest if > > > possible. It is also the approach that kvm guys suggested: > > > https://www.mail-archive.com/kvm@vger.kernel.org/msg102839.html > > >=20 > > > This patch also adds a QOM API object_has_no_children(Object *obj) > > > that checks whether a given object has any child objects. This API > > > is needed to release CPU core and socket objects when a vCPU is destr= oyed. > >=20 > > I'm guessing this commit message needs updating, since you seem to > > have split this out into the previous patch. > >=20 > > > Signed-off-by: Chen Fan > > > Signed-off-by: Gu Zheng > > > Signed-off-by: Zhu Guihua > > > Signed-off-by: Bharata B Rao > > > [Added core and socket removal bits] > > > --- > > > cpus.c | 67 ++++++++++++++++++++++++++++++++++++++++++= ++++++++++ > > > include/qom/cpu.h | 11 +++++++++ > > > include/sysemu/kvm.h | 1 + > > > kvm-all.c | 57 ++++++++++++++++++++++++++++++++++++++++++= +- > > > kvm-stub.c | 5 ++++ > > > 5 files changed, 140 insertions(+), 1 deletion(-) > > >=20 > > > diff --git a/cpus.c b/cpus.c > > > index 0fac143..325f8a6 100644 > > > --- a/cpus.c > > > +++ b/cpus.c > > > @@ -858,6 +858,47 @@ void async_run_on_cpu(CPUState *cpu, void (*func= )(void *data), void *data) > > > qemu_cpu_kick(cpu); > > > } > > > =20 > > > +static void qemu_destroy_cpu_core(Object *core) > > > +{ > > > + Object *socket =3D core->parent; > > > + > > > + object_unparent(core); > > > + if (socket && object_has_no_children(socket)) { > > > + object_unparent(socket); > > > + } > >=20 > > This seems a bit odd to me. I thought the general idea of the new > > approaches to cpu hotplug meant that the hotplug sequence started from > > the top (the socket or core) and worked down to the threads. Rather > > than starting at the thread, and working up to the core and socket > > level. >=20 > Yes that's true for hotplug as well as hot unplug curently. Plug or > unplug starts at socket, moves down to cores and threads. >=20 > However when the unplug request comes down to the thread, we have to > destroy the vCPU and that's when we end up in this part of the code. Here > the thread (vCPU) unparents itself from the core. The core can't unparent > untill all its threads have unparented themselves. When all threads of a > core are done unparenting, core goes ahead and unparents itself from > its parent socket. Similarly socket can unparent when all cores under > it have unparented themselves from the socket. Why can't the core unplug routine propagte the unplug down to the threads, let that complete, then do the per-core unplug stuff and remove itself? Is there an asynchronous callback in here somewhere? > This is the code that ensures that the socket device object finally > gets cleared and the id associated with the hot removed socket device > is available for reuse with next hotplug. >=20 > >=20 > > > +} > > > + > > > +static void qemu_kvm_destroy_vcpu(CPUState *cpu) > > > +{ > > > + Object *thread =3D OBJECT(cpu); > > > + Object *core =3D thread->parent; > > > + > > > + CPU_REMOVE(cpu); > > > + > > > + if (kvm_destroy_vcpu(cpu) < 0) { > > > + error_report("kvm_destroy_vcpu failed.\n"); > > > + exit(EXIT_FAILURE); > > > + } > > > + > > > + object_unparent(thread); > > > + if (core && object_has_no_children(core)) { > > > + qemu_destroy_cpu_core(core); > > > + } > > > +} > > > + >=20 > Regards, > Bharata. >=20 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --iBwuxWUsK/REspAd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVSrqrAAoJEGw4ysog2bOSoI8P/iw7ZWMRsepeOn2JrUz65Ib4 mYpB+usT5LX6EY/GeWA9keTS7haPP6WkYCa8yt4fjT/1VcE8GTR+slHHMZk3EEds cu/84PS/8smPou48P0yyJGRY736vxqcBqirJ/fAMANuIcg2LIYBzCOwMgUXsUeG2 P4wX9sZ8R7vFzduo6jRZyJXHU34XWN7/2lwk5BuP3RdbdRq3uErPR72DD5lVI0ql kwcQAhtu+geOhBOOKizZnZcb9voTpgEEnEMH5q9Uo0VvnnsL9npa9HuqE6tYvYax fCL/cSHwJjF6Zqb34pgFM6pPMkBEoHcTZIBW3FiA7OrwnECH++POc43kR1pngwoZ 2TfiAHz/w5f3WIRKs12zExIb1vcNYD58lZc6jsiH/w9pxZRHCCzs8IGf9jScPKi9 HhgHpVPaiia6PusW24uxsht1RnYR+q/+xivmQ6rPqsaJaX0kPHovj0srzVOP3YWu JHPNOW88HaVi3X/qVLNSNUeqXo8PZHtwMEEaAzlfIvgm6C60ZYQPszQ+eJCDUx/V 0mcVoZ8xhkXjwkgSI8eWIVbj8G/CxtY5f9XAj3JQ8yUVKwPUxfPbCNVgTWoh/Z5L uSnvpqonU8i49jKX79tdrQS5rPQrUCH5YyQVJtGbyYCmAszYv6yDieXGHYet2Mde 74ts2f/vnSLDuBZ51/bs =QYpn -----END PGP SIGNATURE----- --iBwuxWUsK/REspAd--