From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaxFV-0006jS-IL for qemu-devel@nongnu.org; Wed, 25 Mar 2015 22:10:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaxFR-0003aq-5K for qemu-devel@nongnu.org; Wed, 25 Mar 2015 22:10:21 -0400 Date: Thu, 26 Mar 2015 12:46:05 +1100 From: David Gibson Message-ID: <20150326014605.GK28039@voom.redhat.com> References: <1427117764-23008-1-git-send-email-bharata@linux.vnet.ibm.com> <1427117764-23008-18-git-send-email-bharata@linux.vnet.ibm.com> <20150325052439.GB25043@voom.fritz.box> <20150325091224.GG32581@in.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2feizKym29CxAecD" Content-Disposition: inline In-Reply-To: <20150325091224.GG32581@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 17/23] xics_kvm: Don't enable KVM_CAP_IRQ_XICS if already enabled List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: mdroth@linux.vnet.ibm.com, agraf@suse.de, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, tyreld@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com, imammedo@redhat.com, afaerber@suse.de --2feizKym29CxAecD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2015 at 02:42:24PM +0530, Bharata B Rao wrote: > On Wed, Mar 25, 2015 at 04:24:39PM +1100, David Gibson wrote: > > On Mon, Mar 23, 2015 at 07:05:58PM +0530, Bharata B Rao wrote: > > > When supporting CPU hot removal by parking the vCPU fd and reusing > > > it during hotplug again, there can be cases where we try to reenable > > > KVM_CAP_IRQ_XICS CAP for the vCPU for which it was already enabled. > > > Introduce a boolean member in ICPState to track this and don't > > > reenable the CAP if it was already enabled earlier. > > >=20 > > > This change allows CPU hot removal to work for sPAPR. > > >=20 > > > Signed-off-by: Bharata B Rao > >=20 > > Why does double enabling the capability cause problems? I would have > > expected it to be unnecessary, but harmless. >=20 > We are reusing the vCPU here w/o closing its fd. >=20 > As things stand currently, enabling this cap again will result in > kernel trying to create and associate ICP with this vCPU and that > fails since there is already an ICP associated with it. >=20 > Ref: arch/powerpc/kvm/book3s_xics.c:kvmppc_xics_connect_vcpu() kernel cod= e. Ah, right. Sounds like a kernel bug - I would expect enabling a capability to be idempotent. But since the bug's there, we have to work around it now, so ok. > So this patch will ensure that we don't renable this cap. >=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 --2feizKym29CxAecD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVE2TdAAoJEGw4ysog2bOSM+4P/jXZnOqRhePV88DU7plHBfGv BZXeL1NhC9ti6tDRk/uylEhy+0hVRz+RJ6x0Pf4anhfmZaC2rNGfdSwd4Wp2bEfA CB77pN6/e9xRiumEslNFvZSRUZRJzi1L31yA8Lip8MN9gZ+/7IGTLo6fh6egWb1L CQPs46A6s87W+2aDJ/LAIXwRvjtewZNepc4T9fWfG1V/wGhE3SLI3PbvV1vYIkMP tLrkKjaGgNeUUcG0QYAALWGen/mAtHuhn9HWfgZC1TJPpzQoseCLGqGPgIXd4Cks aEYOFEZZ765RFoI7zQ51oyscDT80dvJJbA9VyBwQVdJexNyb3lPBjL8+CrLushGw 1Pzy1knq/dkRdA7BWAPbv+yU3pGweHLKODlNGdSXlF38hmDu3p+pZdWD1uyR+aiN sRe3PIg1ePeAZtWn2K7QIDkwUt0mD9vpeWuclXoEuRhA17WCwWNA6EvzQl3WhnZx alIGG1sYP5Zg6K2d0k0DaIsUQMGFToK6SamDieWS+KikZzpGegBv2vM+2i/tducM l+hAyBq4loJiT5MIUhF3L3XUZYQfs6bdhmwNX+mKWXPHoE1CtiCGqjkwbF3GvwTh tZa8ugsx9MlHb0vGSknMZ+HnkO2q376Bex72iPkQ0kNKJgfeN4smrpSZKZEV73ds poHih2zIYp1zg4vOtzJO =WEW/ -----END PGP SIGNATURE----- --2feizKym29CxAecD--