From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCkiR-0000mV-NW for qemu-devel@nongnu.org; Wed, 08 Jul 2015 04:28:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCkiM-0004uk-QW for qemu-devel@nongnu.org; Wed, 08 Jul 2015 04:28:27 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:57809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCkiM-0004uI-KK for qemu-devel@nongnu.org; Wed, 08 Jul 2015 04:28:22 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 8 Jul 2015 02:28:20 -0600 Message-ID: <559CDF1D.9090103@linux.vnet.ibm.com> Date: Wed, 08 Jul 2015 13:58:13 +0530 From: Aravinda Prasad MIME-Version: 1.0 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> <55950058.8040508@ozlabs.ru> <20150703060102.GB16378@voom.redhat.com> In-Reply-To: <20150703060102.GB16378@voom.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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, Alexey Kardashevskiy , Alexander Graf , qemu-devel@nongnu.org, paulus@samba.org, qemu-ppc@nongnu.org On Friday 03 July 2015 11:31 AM, David Gibson wrote: > On Thu, Jul 02, 2015 at 07:11:52PM +1000, Alexey Kardashevskiy wrote: >> 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... > > Ok, well someone who cares about FWNMI is going to have to start > sending something, or it won't happen. I am yet to work on the new approach proposed above. I will start looking into that this week. > -- Regards, Aravinda