From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqy9X-0004Kd-RJ for qemu-devel@nongnu.org; Wed, 19 Nov 2014 00:50:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xqy9O-0008CD-Ag for qemu-devel@nongnu.org; Wed, 19 Nov 2014 00:50:07 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:57672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqy9O-00088W-5G for qemu-devel@nongnu.org; Wed, 19 Nov 2014 00:49:58 -0500 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 19 Nov 2014 00:49:35 -0500 Message-ID: <546C2F4A.5010708@linux.vnet.ibm.com> Date: Wed, 19 Nov 2014 11:18:58 +0530 From: Aravinda Prasad MIME-Version: 1.0 References: <20141105071019.26196.93729.stgit@aravindap> <20141111032421.GH15270@voom.redhat.com> In-Reply-To: <20141111032421.GH15270@voom.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [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: David Gibson , benh@au1.ibm.com, aik@au1.ibm.com, Alexander Graf Cc: paulus@samba.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org 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? -- Regards, Aravinda