From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXHpz-0002eo-Lo for qemu-devel@nongnu.org; Wed, 02 Sep 2015 19:53:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXHpw-0004hb-Fh for qemu-devel@nongnu.org; Wed, 02 Sep 2015 19:53:07 -0400 Date: Thu, 3 Sep 2015 09:53:20 +1000 From: David Gibson Message-ID: <20150902235320.GC6537@voom.redhat.com> References: <551CC55B.3050901@ozlabs.ru> <20150402044625.GA25823@voom.redhat.com> <55950058.8040508@ozlabs.ru> <20150703060102.GB16378@voom.redhat.com> <559CDF1D.9090103@linux.vnet.ibm.com> <20150807033745.GA4645@tungsten.ozlabs.ibm.com> <55C75B3E.70409@suse.de> <20150810040555.GA9392@tungsten.ozlabs.ibm.com> <55E58707.1030904@linux.vnet.ibm.com> <20150902063401.GA12512@tungsten.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dkEUBIird37B8yKS" Content-Disposition: inline In-Reply-To: <20150902063401.GA12512@tungsten.ozlabs.ibm.com> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu for powerKVM guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sam Bobroff Cc: benh@au1.ibm.com, Alexander Graf , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Aravinda Prasad , paulus@samba.org --dkEUBIird37B8yKS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 02, 2015 at 04:34:01PM +1000, Sam Bobroff wrote: > On Tue, Sep 01, 2015 at 04:37:51PM +0530, Aravinda Prasad wrote: > >=20 > >=20 > > On Monday 10 August 2015 09:35 AM, Sam Bobroff wrote: > > > On Sun, Aug 09, 2015 at 03:53:02PM +0200, Alexander Graf wrote: > > >> > > >> > > >> On 07.08.15 05:37, Sam Bobroff wrote: [snip] > > >>> (c) Assemble it (as above) but include it directly in the QEMU bina= ry by > > >>> objcopying it in or hexdumping into a C string or something similar= =2E This seems > > >>> fairly neat but I'm not sure how people would feel about including = "binaries" > > >>> into QEMU this way. Although it would take some work in the build = system, it > > >>> seems like a fairly neat solution to me. > > >> > > >> We tried to move away from code as hex arrays in QEMU to make it eas= ier > > >> for people to patch things when they want to. But then again if we're > > >> talking 3 instructions it might not be the worst option. > > >=20 > > > Sounds sensible. > > >=20 > > > So, in summary, it sounds like a decent approach would be: > > > * store the guest's handlers in QEMU's spapr structure, > > > * simplify the trampolines down to a single, non-returning, hcall, > >=20 > > However, other instructions such as saving r3 and re-trying hcall are > > still required. >=20 > Ah yes, that's true. I was thinking that the retrying could happen inside= the > hcall but it can't. Sorry, I may have missed something here. What does the code in the vector need to retry? Also, it looks like the vector will need at least one scratch register (for the hcall number, if nothing else). Does PAPR specify what SPRGs the vector can clobber? Obviously it can't be anything the guest kernel uses. Btw, does anyone know what happens with the VPA (and dispatch trace log and so forth) on kexec() - it could be subject to the same stale address problem, and rewriting vectors won't save us there. --=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 --dkEUBIird37B8yKS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV54vwAAoJEGw4ysog2bOSNgUP/1gNWCDVADZhH1JLb0RYctSw 5izkScLxupaQ7WrZApUHgre6HYvLXKyvmvlSL0T2U0F5L49aHCMNOiLbeogmdB8k yy4kwK7E2R2QsICwgR5uTIRWloZEQHf1SmRnfkP4hVR+xLRIQ6rrpxZc0fmI5B+e Cdc+wc4ClcY9VqDIwPfBGZ/+fT0NikQ2URRN53GkIZtvct/FLcBU1wPvdsPSnRVe ft+LUg6bm3/h3Cw9GGC/XxhiHRfUk6/efTuNmpURQ0w1Glo/cAy40hDEogaksZ5H JomGy5JvMiwnvLzTs8BwP3bQV7YPBxde0y6traZfe4fJLLNhJtsmKziwriFGG/m0 yjpXS/jSX55JR9ChCK4KpMz9tj2stb7NzJeOiMZPh4YwHKW/U1+H30kstHgZ1Vpc WhEeD9Li11CmPH+bMBdApM11egW4Q63crjKLhoLgAA5dTFGqN4WmoySMpGuRUmav X4n76De27l/SiSut4oVO3YfseAFxHBolPVZBFdNI52B0I0dNikyeg5KBalBJIJAA ka8r1MzZkwefBP3SzhzQT0Kcwnua9oZUEoOST09/ONTIbwZ5C+2fgAFTIerv3bDI W5XbeKDHlXWCqz6NdnX7RlXcizQRenV4fWdQSaw0/xeDjKSPzA0RwNJ9JG69XPIV /WrN2r1A4EOX0QegUBus =26fU -----END PGP SIGNATURE----- --dkEUBIird37B8yKS--