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 <aravi...@linux.vnet.ibm.com> >> >> 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