From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bandan Das <bsd@redhat.com>
Subject: Re: [Qemu-devel] E5-2620v2 - emulation stop error
Date: Wed, 11 Mar 2015 13:09:42 -0400
Message-ID: <jpgvbi7v4tl.fsf@redhat.com>
References: <jpgwq2uqd1h.fsf@redhat.com>
	<CABYiri-u0Spd9u1mBNqYiD9t4n2hC65_pGHBdhnPeEgXtbnFEQ@mail.gmail.com>
	<CABYiri-oXA9eMqWDd+qXGozcZaVLLTocRpUwKnvBy-GAc69fnw@mail.gmail.com>
	<20150310165755.GL2338@work-vm> <54FF337A.1010202@redhat.com>
	<jpgoao0r9vh.fsf@redhat.com> <54FF4541.9080608@redhat.com>
	<20150310202958.GR2338@work-vm> <jpgbnk01cn2.fsf@redhat.com>
	<20150311134556.GH2334@work-vm>
	<20150311154220.GA26463@morn.localdomain>
Mime-Version: 1.0
Content-Type: text/plain
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, kraxel@redhat.com,
	Andrey Korolyov <andrey@xdel.ru>,
	"qemu-devel\@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm\@vger.kernel.org" <kvm@vger.kernel.org>
To: "Kevin O'Connor" <kevin@koconnor.net>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:44950 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752168AbbCKRJr (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 11 Mar 2015 13:09:47 -0400
In-Reply-To: <20150311154220.GA26463@morn.localdomain> (Kevin O'Connor's
	message of "Wed, 11 Mar 2015 11:42:20 -0400")
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

"Kevin O'Connor" <kevin@koconnor.net> writes:
...
>
> Something is very odd here.  When I run the above command (on an older
> AMD machine) I get:
>
> Found 128 cpu(s) max supported 128 cpu(s)
>
> That first value (1 vs 128) comes from QEMU (via cmos index 0x5f).
> That is, during smp init, SeaBIOS expects QEMU to tell it how many
> cpus are active, and SeaBIOS waits until that many CPUs check in from
> its SIPI request before proceeding.
>
> I wonder if QEMU reported only 1 active cpu via that cmos register,
> but more were actually active.  If that was the case, it could

I was daring enough to try this and I don't see the crash :)

diff --git a/src/fw/smp.c b/src/fw/smp.c
index a466ea6..a346d46 100644
--- a/src/fw/smp.c
+++ b/src/fw/smp.c
@@ -49,6 +49,7 @@ int apic_id_is_present(u8 apic_id)
 void VISIBLE32FLAT
 handle_smp(void)
 {
+  dprintf(DEBUG_HDL_smp, "Calling handle_smp\n");
     if (!CONFIG_QEMU)
         return;
 
@@ -128,6 +129,8 @@ smp_setup(void)
 
     // Wait for other CPUs to process the SIPI.
     u8 cmos_smp_count = rtc_read(CMOS_BIOS_SMP_COUNT) + 1;
+    while (cmos_smp_count == 1)
+        cmos_smp_count = rtc_read(CMOS_BIOS_SMP_COUNT) + 1;
     while (cmos_smp_count != CountCPUs)
         asm volatile(
             // Release lock and allow other processors to use the stack.

So, the while loop results in a race somehow ?

Bandan
> certainly explain the failure - as multiple cpus could be running
> without the sipi trapoline in place.
>
> What does the log look like on a non-failure case?
>
> -Kevin