From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4oaf-000415-6r for qemu-devel@nongnu.org; Tue, 16 Jun 2015 06:59:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4oaa-0000bX-TE for qemu-devel@nongnu.org; Tue, 16 Jun 2015 06:59:37 -0400 Received: from mail-yk0-f177.google.com ([209.85.160.177]:33176) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4oaa-0000bG-PI for qemu-devel@nongnu.org; Tue, 16 Jun 2015 06:59:32 -0400 Received: by ykfr66 with SMTP id r66so10095741ykf.0 for ; Tue, 16 Jun 2015 03:59:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <557B0B21.2030009@hs-rm.de> <557EE4D2.5010202@hs-rm.de> <557EE9B3.1030606@hs-rm.de> <557F2F8C.8090708@hs-rm.de> From: Peter Maydell Date: Tue, 16 Jun 2015 11:59:11 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] QEMU ARM SMP: IPI delivery delayed until next main loop event // how to improve IPI latency? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Zuepke Cc: QEMU Developers On 16 June 2015 at 11:33, Peter Maydell wrote: > Pressing a key does not unwedge the test case for me. Looking at the logs, this seems to be expected given what the guest code does with CPU #1: (the below is edited logs, created with a hacky patch I have that annotates the debug logs with CPU numbers): CPU #1: Trace 0x7f2d67afa000 [80000100] _start # we start CPU #1: Trace 0x7f2d67afc060 [8000041c] main_cpu1 # we correctly figured out we're CPU 1 CPU #1: Trace 0x7f2d67afc220 [80000448] main_cpu1 # we took the branch to 80000448 CPU #1: Trace 0x7f2d67afc220 [80000448] main_cpu1 # 8000448 is a branch-to-self, so here we stay CPU #1 never bothered to enable its GICC cpu interface, so it will never receive interrupts and will never get out of this tight loop. We get here because CPU #1 has got through main_cpu1 to the point of testing your 'release' variable before CPU #0 has got through main_cpu0 far enough to set it to 1, so it still has the zero in it that it has on system startup. If scheduling happened to mean that CPU #0 ran further through main_cpu0 before CPU #1 ran, we wouldn't end up in this situation -- you have a race condition, as I suggested. The log shows we're sat with CPU#0 fruitlessly looping on a variable in memory, and CPU#1 in this endless loop. PS: QEMU doesn't care, but your binary seems to be entirely devoid of barrier instructions, which is likely to cause you problems on real hardware. thanks -- PMM