From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMvC7-0004cY-Rj for qemu-devel@nongnu.org; Thu, 28 Aug 2014 04:36:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XMvC0-0003Xp-Bh for qemu-devel@nongnu.org; Thu, 28 Aug 2014 04:36:35 -0400 Message-ID: <53FEEA0A.4060204@suse.de> Date: Thu, 28 Aug 2014 10:36:26 +0200 From: Alexander Graf MIME-Version: 1.0 References: <20140825134353.2361.52046.stgit@aravindap> <20140825134535.2361.37728.stgit@aravindap> <53FDA9EB.5010301@suse.de> <53FEC868.9060009@linux.vnet.ibm.com> In-Reply-To: <53FEC868.9060009@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/5] target-ppc: Build error log List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aravinda Prasad Cc: qemu-ppc@nongnu.org, benh@au1.ibm.com, aik@au1.ibm.com, qemu-devel@nongnu.org, paulus@samba.org On 28.08.14 08:12, Aravinda Prasad wrote: > > > On Wednesday 27 August 2014 03:20 PM, Alexander Graf wrote: >> >> >> On 25.08.14 15:45, Aravinda Prasad wrote: >>> Whenever there is a physical memory error due to bit >>> flips, which cannot be corrected by hardware, the error >>> is passed on to the kernel. If the memory address in >>> error belongs to guest address space then guest kernel >>> is responsible to take action. Hence the error is passed >>> on to guest via KVM by invoking 0x200 NMI vector. >>> >>> However, guest OS, as per PAPR, expects an error log >>> upon such error. This patch registers a new hcall >>> which is issued from 0x200 interrupt vector and builds >>> the error log, copies the error log to rtas space and >>> passes the address of the error log to guest >>> >>> Enhancement to KVM to perform above functionality is >>> already in upstream kernel. >>> >>> Signed-off-by: Aravinda Prasad >> >> Why do we have to maintain the error log inside the rtas blob? Can't we >> just create a fixed MMIO region that is backed by an error log device in >> QEMU? >> >> Then this call would just always return that specific address and we'd >> also have a single file that deals with all of the error reporting. > > PAPR requires error log to be inside rtas space. Hence guest OS > explicitly checks if error log is inside rtas space. > > VALID_FWNMI_BUFFER does this check inside fwnmi_get_errinfo() in the kernel. So why not put it at 0x7000 then? Alex