From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAaXW-0006wV-6e for qemu-devel@nongnu.org; Thu, 02 Jul 2015 05:12:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAaXQ-0004XQ-5c for qemu-devel@nongnu.org; Thu, 02 Jul 2015 05:12:14 -0400 Received: from mail-pd0-f170.google.com ([209.85.192.170]:35818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAaXQ-0004Va-01 for qemu-devel@nongnu.org; Thu, 02 Jul 2015 05:12:08 -0400 Received: by pdbci14 with SMTP id ci14so41814461pdb.2 for ; Thu, 02 Jul 2015 02:12:06 -0700 (PDT) References: <20141105071019.26196.93729.stgit@aravindap> <20141111032421.GH15270@voom.redhat.com> <546C2F4A.5010708@linux.vnet.ibm.com> <551CC55B.3050901@ozlabs.ru> <20150402044625.GA25823@voom.redhat.com> From: Alexey Kardashevskiy Message-ID: <55950058.8040508@ozlabs.ru> Date: Thu, 2 Jul 2015 19:11:52 +1000 MIME-Version: 1.0 In-Reply-To: <20150402044625.GA25823@voom.redhat.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: David Gibson Cc: benh@au1.ibm.com, aik@au1.ibm.com, Alexander Graf , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Aravinda Prasad , paulus@samba.org On 04/02/2015 03:46 PM, David Gibson wrote: > 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? >> >> >> Any updates about FWNMI? Thanks > > Huh.. I'd completely forgotten about this. Aravinda, can you repost > your latest work on this? Aravinda disappeared... -- Alexey