From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ag3j6-0002G9-Jw for qemu-devel@nongnu.org; Wed, 16 Mar 2016 01:10:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ag3j4-0006f2-Ez for qemu-devel@nongnu.org; Wed, 16 Mar 2016 01:10:32 -0400 Date: Wed, 16 Mar 2016 16:11:35 +1100 From: David Gibson Message-ID: <20160316051135.GD9032@voom> References: <1458016736-10544-1-git-send-email-bharata@linux.vnet.ibm.com> <1458016736-10544-3-git-send-email-bharata@linux.vnet.ibm.com> <20160316013605.GC9032@voom> <20160316044154.GD13176@in.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AouxlZHmRoNegvUM" Content-Disposition: inline In-Reply-To: <20160316044154.GD13176@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 2/2] spapr: Memory hot-unplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: thuth@redhat.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, qemu-ppc@nongnu.org, nfont@linux.vnet.ibm.com, imammedo@redhat.com --AouxlZHmRoNegvUM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2016 at 10:11:54AM +0530, Bharata B Rao wrote: > On Wed, Mar 16, 2016 at 12:36:05PM +1100, David Gibson wrote: > > On Tue, Mar 15, 2016 at 10:08:56AM +0530, Bharata B Rao wrote: > > > Add support to hot remove pc-dimm memory devices. > > >=20 > > > Signed-off-by: Bharata B Rao > >=20 > > Reviewed-by: David Gibson > >=20 > > Looks correct, but again, needs to wait on the PAPR change. > >=20 > > Have you thought any further on the idea of sending an index message, > > then a count message as an interim approach to fixing this without > > requiring a PAPR change? >=20 > Removal by index and removal by count are valid messages by themselves > and drmgr would go ahead and start the removal in reponse to those > calls. IIUC, you are suggesting that lets remove one LMB by index in > response to 1st message and remove (count -1) LMBs from where the last > removal was done in the previous message. That's right. > Since the same code base of powerpc-utils works on PowerVM too, I am not > sure if such an approach would impact PowerVM in any undesirable manner. > May be Nathan can clarify ? Ah.. My first guess would be that it's ok; since IIUC PowerVM doesn't care where the LMBs are removed from, removing them starting from the last place we removed something should be as good as anywhere. But it's possible there's some issue I haven't considered. > I see that this can be done, but the changes in drmgr code specially the > code related to LMB list handling/removal can be non-trivial. So not sure > if the temporary approach is all that worth here and hence I feel it is b= etter > to wait and do it the count-indexed way. Ok. It seems like it ought to be fairly straightforward, but I don't know the drmgr code, so.. It would certainly be useful if Nathan could chime in on this. > While we are here, I would also like to get some opinion on the real > need for memory unplug. Is there anything that memory unplug gives us > which memory ballooning (shrinking mem via ballooning) can't give ? That's.. a good question. I guess it means avoiding another interface and a pseudo-device at least. --=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 --AouxlZHmRoNegvUM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW6OsHAAoJEGw4ysog2bOSmloP/2SC74QeUy/Jg6m8uda4SZrN 3IbJ0VdNtbs55Xo4oB59j7WNqqg3jHjoN1Owm8SwSqrYu81fXO6UUGtJUHXzL3RT qk7KLMOppTo0RlXFIQeHmMng4Ep0SAUXVczNKU/lYAGCcHmHzOpkVS8wtTJkIdMF Bhn568HI4/yjljqJMJoXlOynfQNOIbqsYttEzjQzbmwa2ZnbI4yut13bIQ2qV3SA 4SHQPrm21YsYl0Tjp8gla+0mYOuUDdgOVzMPbJsE/ej+xmIdFrYR5ejDGWACPGvE JOt1spDuxxz7TWUVelcXt3q/Rm5Bt/6IeAd9VcbpMbZLP502L22i/A1nniJBWYIV KUIzCWMxfaXDaN4AK8VHvBmB7jbVuGK3ikJrV73/F5l0006PcBOR2FeZHLR5XUuT wsFCnh0fjgDAt/YsJ42LN1eQFJI/W6v1sgFLmRGT6S0OQExTMXAD2wztEBixM+VY N6/C6/wlebvgrjqyuAyodz8ZDz4U8HNFMB6/8dtdmPcokbRbUsX4L/2KtIJkFSh7 5qNcu0oRtxt5bzUPcVtGjWK3pW0yKF1AgJ3p4atylLwJ98tD1oRj619Wur4a3X+E N0Lc34CCkJsXUJRxOtHiBFkGQIgzAto4SCHbutzp2iAfhPnk30MPfaoVLiTLcvFb MaFac5mdRQ6OIRX0cwkw =jFsV -----END PGP SIGNATURE----- --AouxlZHmRoNegvUM--