From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38431) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdWjx-0001Pl-08 for qemu-devel@nongnu.org; Thu, 02 Apr 2015 00:28:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdWjt-0003aY-0r for qemu-devel@nongnu.org; Thu, 02 Apr 2015 00:28:24 -0400 Received: from mail-pd0-f176.google.com ([209.85.192.176]:33205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdWjs-0003aG-RD for qemu-devel@nongnu.org; Thu, 02 Apr 2015 00:28:20 -0400 Received: by pdrw1 with SMTP id w1so68583666pdr.0 for ; Wed, 01 Apr 2015 21:28:19 -0700 (PDT) Message-ID: <551CC55B.3050901@ozlabs.ru> Date: Thu, 02 Apr 2015 15:28:11 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <20141105071019.26196.93729.stgit@aravindap> <20141111032421.GH15270@voom.redhat.com> <546C2F4A.5010708@linux.vnet.ibm.com> In-Reply-To: <546C2F4A.5010708@linux.vnet.ibm.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit 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: Aravinda Prasad , aik@au1.ibm.com, Alexander Graf Cc: qemu-ppc@nongnu.org, benh@au1.ibm.com, paulus@samba.org, qemu-devel@nongnu.org, David Gibson 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? Any updates about FWNMI? Thanks -- Alexey