From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMvHq-0001SD-H2 for qemu-devel@nongnu.org; Thu, 28 Aug 2014 04:42:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XMvHj-0005Yx-1I for qemu-devel@nongnu.org; Thu, 28 Aug 2014 04:42:30 -0400 Message-ID: <53FEEB6D.7090305@suse.de> Date: Thu, 28 Aug 2014 10:42:21 +0200 From: Alexander Graf MIME-Version: 1.0 References: <20140825134353.2361.52046.stgit@aravindap> <20140825134554.2361.45051.stgit@aravindap> <53FDB587.1030505@suse.de> <53FED294.7090000@linux.vnet.ibm.com> In-Reply-To: <53FED294.7090000@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 5/5] target-ppc: Handle cases when multi-processors get machine-check 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:56, Aravinda Prasad wrote: > > > On Wednesday 27 August 2014 04:10 PM, Alexander Graf wrote: >> >> >> On 25.08.14 15:45, Aravinda Prasad wrote: >>> It is possible for multi-processors to experience machine >>> check at or about the same time. As per PAPR, subsequent >>> processors serialize waiting for the first processor to >>> issue the ibm,nmi-interlock call. >>> >>> The second processor retries if the first processor which >>> received a machine check is still reading the error log >>> and is yet to issue ibm,nmi-interlock call. >>> >>> This patch implements this functionality. >>> >>> Signed-off-by: Aravinda Prasad >> >> This patch doesn't make any sense. Both threads will issue an HCALL >> which will get locked inside of QEMU, so we'll never see the case where >> both hypercalls get processed at the same time. > > AFAIK, only one thread can succeed entering qemu upon parallel hcall > from different guest CPUs as it is gated by a lock. Hence one hcall is > processed at a time. > > As per PAPR, we don't want any other KVMPPC_H_REPORT_ERR hcall to be > processed at the same time and further KVMPPC_H_REPORT_ERR hcall thus > issued should wait until the OS issues ibm,nmi-interlock. Oh, now I understand. The locking time is from [h_report_mc_err...rtas_ibm_nmi_interlock]. This should definitely go into the comment on the check in h_report_mc_err. In fact, remove the fact that only one thread can execute and instead write where the lock gets unset and that during that phase only one vcpu may process the NMI. Alex