qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin O'Connor <kevin@koconnor.net>
To: "Xulei (Stone)" <stone.xulei@huawei.com>
Cc: "Huangweidong (C)" <weidong.huang@huawei.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform
Date: Thu, 19 Nov 2015 08:40:40 -0500	[thread overview]
Message-ID: <20151119134039.GA27717@morn.lan> (raw)
In-Reply-To: <8E78D212B8C25246BE4CE7EA0E645FE52B72B7@SZXEMI504-MBS.china.huawei.com>

On Thu, Nov 19, 2015 at 12:42:50PM +0000, Xulei (Stone) wrote:
> Kevin,
> 
> After deeply analyzing, i think there may be 3 possible reasons:
> 1)wrong CountCPUs value. It seems CountCPUs++ in handle_smp() has no
> lock to protect.  So, sometimes, 2 or more vcpu may get the same
> current value of CountCPUs. Then we'll get a single incrementation
> instead of 2 or more and "while (cmos_smp_count != CountCPUs)" will
> loop forever;

The handle_smp() code is called from romlayout.S:entry_smp() which
does take a lock.  So, all of handle_smp() should run synchronous.

> 2)wrong cmos_smp_count value. SeaBIOS rtc reads an incorrect number?

Not sure - the last time there were problems in this area of the code
others used kvmtrace to try and track this down.  Since you are
getting dprintf statements, you could also try outputting
cmos_smp_count prior to the loop (see patch below).

> 3)yield() stuck. Is it possible that SeaBIOS is stuck during yield?
> I've tested, when yield() is running, SeaBIOS seems has not created
> some other threads except the main thread. So I don't know what's
> the function of yield() here.?

The yield() allows hardware interrupts to occur.  But note that
yield() isn't called in the loop - is is only called after the loop
completes.

If you are only getting this on massive repetitive reboot requests,
there are some other possible explanations:

- perhaps the SIPI is getting lost because one of the CPUs is still
  resetting or still processing a SIPI from the last reboot?

- the seabios code itself may have been corrupted if the memcpy() in
  qemu_prep_reset() got far enough along to clear HaveRunPost, but did
  not get far enough along to fully complete the memcpy().

If the failure is reproducible, the patch below could help narrow the
possibilities.

-Kevin


--- a/src/fw/smp.c
+++ b/src/fw/smp.c
@@ -125,6 +125,7 @@ smp_setup(void)
 
     // Wait for other CPUs to process the SIPI.
     u8 cmos_smp_count = rtc_read(CMOS_BIOS_SMP_COUNT) + 1;
+    dprintf(1, "cmos_smp_count=%d\n", cmos_smp_count);
     while (cmos_smp_count != CountCPUs)
         asm volatile(
             // Release lock and allow other processors to use the stack.
@@ -136,6 +137,7 @@ smp_setup(void)
             "  jc 1b\n"
             : "+m" (SMPLock), "+m" (SMPStack)
             : : "cc", "memory");
+    dprintf(1, "finish smp\n");
     yield();
 
     // Restore memory.

  reply	other threads:[~2015-11-19 13:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03  6:58 [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform Xulei (Stone, Euler)
2015-11-04  0:48 ` Gonglei
2015-11-04 17:42   ` Kevin O'Connor
2015-11-06  9:12     ` Xulei (Stone)
2015-11-09 13:32       ` Kevin O'Connor
2015-11-09 20:06         ` Kevin O'Connor
2015-11-09 20:27           ` Kevin O'Connor
2015-11-19  1:04             ` Xulei (Stone)
2015-11-19 12:42               ` Xulei (Stone)
2015-11-19 13:40                 ` Kevin O'Connor [this message]
2015-11-20  2:05                   ` Xulei (Stone)
     [not found]                   ` <33183CC9F5247A488A2544077AF19020B02B72BA@SZXEMA503-MBS.china.huawei.com>
2015-12-18 23:13                     ` Kevin O'Connor
2015-12-19  6:28                       ` Gonglei (Arei)
2015-12-19 12:03                       ` Gonglei (Arei)
2015-12-19 15:11                         ` Kevin O'Connor
2015-12-20  9:49                           ` Gonglei (Arei)
2015-12-20 14:33                             ` Kevin O'Connor
2015-12-21  9:41                               ` Gonglei (Arei)
2015-12-21 18:47                                 ` Kevin O'Connor
2015-12-22  2:14                                   ` Gonglei (Arei)
2015-12-22  3:15                                     ` Xulei (Stone)
2015-12-22 15:38                                       ` Kevin O'Connor
2015-12-22 15:51                                     ` Kevin O'Connor
2015-12-23  6:40                                       ` Gonglei (Arei)
2015-12-23 18:06                                         ` Kevin O'Connor
2015-12-19  1:08                   ` Gonglei (Arei)
  -- strict thread matches above, loose matches on Subject: below --
2015-11-04  0:19 Xulei (Stone, Euler)
2015-11-03  6:29 Xulei (Stone, Euler)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151119134039.GA27717@morn.lan \
    --to=kevin@koconnor.net \
    --cc=arei.gonglei@huawei.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    --cc=stone.xulei@huawei.com \
    --cc=weidong.huang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).