From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdXWp-0001w7-Fc for qemu-devel@nongnu.org; Thu, 02 Apr 2015 01:18:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdXWm-0003D2-9p for qemu-devel@nongnu.org; Thu, 02 Apr 2015 01:18:55 -0400 Date: Thu, 2 Apr 2015 15:46:25 +1100 From: David Gibson Message-ID: <20150402044625.GA25823@voom.redhat.com> References: <20141105071019.26196.93729.stgit@aravindap> <20141111032421.GH15270@voom.redhat.com> <546C2F4A.5010708@linux.vnet.ibm.com> <551CC55B.3050901@ozlabs.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <551CC55B.3050901@ozlabs.ru> 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: Alexey Kardashevskiy Cc: benh@au1.ibm.com, aik@au1.ibm.com, Alexander Graf , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Aravinda Prasad , paulus@samba.org --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 02, 2015 at 03:28:11PM +1100, Alexey Kardashevskiy wrote: > On 11/19/2014 04:48 PM, Aravinda Prasad wrote: > > > > > >On Tuesday 11 November 2014 08:54 AM, David Gibson wrote: > > > >[..] > > > >> > >>So, this may not still be possible depending on whether the KVM side > >>of this is already merged, but it occurs to me that there's a simpler > >>way. > >> > >>Rather than mucking about with having to update the hypervisor on the > >>RTAS location, they have qemu copy the code out of RTAS, patch it and > >>copy it back into the vector, you could instead do this: > >> > >> 1. Make KVM instead of immediately delivering a 0x200 for a guest > >>machine check, cause a special exit to qemu. > >> > >> 2. Have the register-nmi RTAS call store the guest side MC handler > >>address in the spapr structure, but perform no actual guest code > >>patching. > >> > >> 3. Allocate the error log buffer independently from the RTAS blob, > >>so qemu always knows where it is. > >> > >> 4. When qemu gets the MC exit condition, instead of going via a > >>patched 0x200 vector, just directly set the guest register state and > >>jump straight into the guest side MC handler. > >> > > > >Before I proceed further I would like to know what others think about > >the approach proposed above (except for step 3 - as per PAPR the error > >log buffer should be part of RTAS blob and hence we cannot have error > >log buffer independent of RTAS blob). > > > >Alex, Alexey, Ben: Any thoughts? >=20 >=20 > Any updates about FWNMI? Thanks Huh.. I'd completely forgotten about this. Aravinda, can you repost your latest work on this? --=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 --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVHMmhAAoJEGw4ysog2bOSK20QAIud94Fc6clpuNYyfk1vbVBd 9JFNTqJ1Y5gzdROen2Yg0jxHX/jvEeAThFHCwjvEA0nujNjW1tXFvcULmAMc9d+V Cp1fIaV1+GrrQUacY8asNvkIHu6y6pdsMJVFbynW5RJ/1uhKZlDabRH3UPCVOzJb LMHLqVuA4OSCOztkXiIRyGoPXKbxYWk+MzwqSVJqkdxlhi0YbkGsgI1+jN8DqME4 c9SuWpfykD3EbjGtae78vFTQ9NQ+dK/NTLX6mHlW/0m9+uc4QGYzTE9458zlWtHA OlfoaYlc175H//hd/M6rQuBpgX6DNliAJQ23q0EOOFmLPuxZlxHZESOKwk4i8qKa vxfEN7nUIzsEwZnY+db/prAbSYglXglB8SEe5nAEDVz/Op3BqjhK5md3PGL39cO+ 0UwEvsMDYrwrcNN6NRE+ddbrMeiMbzFDlfBxeKpXPqVXeimQxkVBlzPDz94N98t7 zZ2ldMOGfWTu4cYk5Hokbyi4pYaRGWKurZT0XgmTFBLBW/BjsNIbT2fzjPTwvsJr pysPjTYm/1lX+f3quTV1QjLLLcRNlW7Nz6WUknG/vSDT0kq1tfitd4GlNsZrnF3V P+y3GHdWmWOezaHSJ/izBmnqeOp0/IikXW2hNb1sac+shqQk6ULBcHsJ04yquhnl f28JRbQPsjmCR8gahbwa =fdtM -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q--