From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4abP-0003f2-J3 for qemu-devel@nongnu.org; Mon, 15 Jun 2015 16:03:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4abM-0008Q3-DF for qemu-devel@nongnu.org; Mon, 15 Jun 2015 16:03:27 -0400 Received: from mxout-1k.itc.hs-rm.de ([195.72.102.133]:41156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4abM-0008OU-3q for qemu-devel@nongnu.org; Mon, 15 Jun 2015 16:03:24 -0400 Message-ID: <557F2F8C.8090708@hs-rm.de> Date: Mon, 15 Jun 2015 22:03:24 +0200 From: Alex Zuepke MIME-Version: 1.0 References: <557B0B21.2030009@hs-rm.de> <557EE4D2.5010202@hs-rm.de> <557EE9B3.1030606@hs-rm.de> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable 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: Peter Maydell Cc: QEMU Developers Am 15.06.2015 um 20:58 schrieb Peter Maydell: > On 15 June 2015 at 16:05, Alex Z=C3=BCpke w= rote: >> Am 15.06.2015 um 16:51 schrieb Peter Maydell: >>> On 15 June 2015 at 15:44, Alex Z=C3=BCpke = wrote: >>>> Am 12.06.2015 um 20:03 schrieb Peter Maydell: >>>>> Probably the best approach would be to have something in >>>>> arm_cpu_set_irq() which says "if we are CPU X and we've >>>>> just caused an interrupt to be set for CPU Y, then we >>>>> should ourselves yield back to the main loop". >>>>> >>>>> Something like this, maybe, though I have done no more testing >>>>> than checking it doesn't actively break kernel booting :-) >>>> >>>> >>>> Thanks! One more check for "level" is needed to get it work: >>> >>> What happens without that? It's reasonable to have it, >>> but extra cpu_exit()s shouldn't cause a problem beyond >>> being a bit inefficient... >> >> The emulation get's stuck, for whatever reason I don't understand. > > I'm beginning to suspect that your guest code has a race > condition in it, such that if the other CPU runs at a > point you weren't expecting it to then you end up > deadlocking or otherwise running into a bug in your guest. > > In particular, I see the emulation getting stuck even without > this patch to arm_cpu_set_irq(). > > -- PMM Yes, it's a bug, sorry for that. I removed too much code to get a simple=20 testcase. It's stuck in the first spinlock where CPU#1 is waiting for=20 CPU#0 to initialize the rest of the system, and I need to WFE or YIELD=20 here as well. But this is showing the original problem again: the emulation get's=20 stuck spinning on CPU #1 forever, because the main loop doesn't switch=20 to CPU #0 voluntarily. Just press a key on the console/emulated serial=20 line to trigger an event to QEMU's main loop, and the testcase should=20 continue. Best regards Alex