From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Subject: Re: [kvm-unit-tests PATCH 2/2] powerpc: restore TOC pointer Date: Wed, 20 Apr 2016 15:59:42 +1000 Message-ID: <20160420155942.3123963e@voom.fritz.box> References: <1461086788-3102-1-git-send-email-lvivier@redhat.com> <1461086788-3102-3-git-send-email-lvivier@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/jlZQfOCdbLkjqN48a9DbHpP"; protocol="application/pgp-signature" Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, drjones@redhat.com, thuth@redhat.com, pbonzini@redhat.com To: Laurent Vivier Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52576 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752142AbcDTF60 (ORCPT ); Wed, 20 Apr 2016 01:58:26 -0400 In-Reply-To: <1461086788-3102-3-git-send-email-lvivier@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: --Sig_/jlZQfOCdbLkjqN48a9DbHpP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 19 Apr 2016 19:26:28 +0200 Laurent Vivier wrote: > As the TOC pointer can be corrupted by the main program, > we must restore it in the exception handler. >=20 > As we know where we are loaded, we can now compute it easily. >=20 > To compute it only in the common part of the exception handler > (call_handler), store the address of call_handler at an absolute > address in memory to be able to call the handler from the exception > table (as SLOF does). >=20 > Reported-by: Thomas Huth > Signed-off-by: Laurent Vivier So, this looks ok as long as the unit tests are built with a single TOC. The more stricly correct approach would be to actually load the correct TOC pointer for the specific handler function you're going to jump to. That would need different paths for ABIv1 and v2, though (in practice ppc64 vs. ppc64le). With ABIv1 (ppc64) you'd need to load the TOC pointer from the procedure descriptor into r2 before jumping to the code address. With ABIv2 (ppc64le), I believe there's both a "far" and "near" entry point to the function - the "far" one has a few instructions to load the correct TOC before continuing onto the "near" version. I forget which entry point the plain symbol references. If it's the "far" one, the current code is probably already correct. > --- > powerpc/cstart64.S | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) >=20 > diff --git a/powerpc/cstart64.S b/powerpc/cstart64.S > index c47b67d..1ddfa13 100644 > --- a/powerpc/cstart64.S > +++ b/powerpc/cstart64.S > @@ -13,6 +13,8 @@ > =20 > #include "spapr.h" > =20 > +#define P_HANDLER 0x2ff8 > + > .section .init > =20 > /* > @@ -46,6 +48,11 @@ start: > add r4, r4, r31 > bl relocate > =20 > + /* compute address of call_handler */ > + > + LOAD_REG_ADDR(r4, call_handler) > + std r4, P_HANDLER(0) > + > /* relocate vector table to base address 0x0 (MSR_IP =3D 0) */ > =20 > /* source: r4, dest end: r5, destination: r6 */ > @@ -166,6 +173,12 @@ call_handler: > mfsrr1 r0 > std r0, _MSR(r1) > =20 > + /* restore TOC pointer */ > + > + LOAD_REG_IMMEDIATE(r31, SPAPR_KERNEL_LOAD_ADDR) > + ld r2, (p_toc - start)(r31) > + add r2, r2, r31 > + > /* FIXME: build stack frame */ > =20 > /* call generic handler */ > @@ -221,7 +234,7 @@ call_handler: > mfctr r0 > std r0,_CTR(r1) > =20 > - LOAD_REG_ADDR(r0, call_handler) > + ld r0, P_HANDLER(0) > mtctr r0 > =20 > li r0,\vec > @@ -245,3 +258,5 @@ VECTOR(0x900) > .align 7 > .globl __end_interrupts > __end_interrupts: > + .org P_HANDLER > + .llong 0 > --=20 > 2.5.5 >=20 --=20 David Gibson Senior Software Engineer, Virtualization, Red Hat --Sig_/jlZQfOCdbLkjqN48a9DbHpP Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFxrOAAoJEGw4ysog2bOSHPQQAON77XDeU/v5j2X3/kUnWcjs 0bf0gr8Dh70hBUUVDSUPzIiczsW/hImTdi/cxfvwnZPI6gnlRwdTY53tziy4z1a4 WfterkuG5IPhvLsiaZ4MsY4Y7ii+CGxpFxLBuU/+MCshAzqTOBsDh72Xuv4ADO2A u9cJwFe8bfkg/ccXc7LYWWgGYlPb3WSh305Ky7vSg0IufNBYiyZ3UZ1TyViPx5NO y/53kbcSxpSD1D5Mf5VFJIpvt4+xyWNFyFXVa4BZqBTy0LU3cmSaz5KM/5GU0jcK JEfBLDfOMuyfFJCtbJpsM/wHKl7DXXMraFu7n33nrVq9EYrueea3aE58DFVmFdYn zvn0y5YY5OBkWlBISGfjitusx4BYH+2p9bDVJcstzB4Egjx9vcPMw+YGjD02x/aA IuEDAdUmcoDQ2LZEsrtS/NgVH7tqBK6YAzDwv5SINT1v6DUTj79rWN6tjwfTBhfo 7ppi+Niejhx6NmriVBo9roRx0BL18CIufOSmxrBV+vMPV1KNA1u70m/tOrKuhH37 D2NdlrhHaQzZqvW21CfdxpQ6lNxmj9LahdxaIsxrAsK7xan195eiv8JXWP2Yjale ij4eihdfJQ7UtBC3IZAcfxikaZOiUosXZr7hQewtQdkY8bv7MPGSSCxyys1RNviE FzkvjHcUWu/DZzkROz48 =s+Fv -----END PGP SIGNATURE----- --Sig_/jlZQfOCdbLkjqN48a9DbHpP--