From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTYyF-0003Zh-1w for qemu-devel@nongnu.org; Mon, 15 Sep 2014 12:17:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTYy8-00079x-3V for qemu-devel@nongnu.org; Mon, 15 Sep 2014 12:17:42 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51807 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTYy7-00079n-TR for qemu-devel@nongnu.org; Mon, 15 Sep 2014 12:17:36 -0400 Message-ID: <54171119.1030902@suse.de> Date: Mon, 15 Sep 2014 18:17:29 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <541235A6.5050006@twiddle.net> <54131349.7010406@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] cpu-exec: Don't mask out external interrupts when single-stepping an invalid instruction. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Martin Galvan , Anthony Liguori , Richard Henderson Am 15.09.2014 um 18:10 schrieb Peter Maydell: > On 15 September 2014 09:02, Martin Galvan > wrote: >> I did a bit more research on how Cortex-M handles nested interrupts. >> In particular, I noticed if we were to have an invalid instruction >> inside the exception handler itself, trying to single-step it would >> again cause Qemu not to return control back to gdb. Reading up a bit I >> found out that when the CPU is handling an exception, all other >> exceptions with the same or lower priority will be blocked. >> >> Qemu seems to implement this by setting the exception as pending, yet >> not changing cpu->interrupt_request so that we modify the PC in the >> second call to do_interrupt. That seems fine to me, but since the >> translation block is the same as before (and if that one contained an >> exception_with_syndrome ending in a call to cpu_loop_exit) we'll be >> stuck in the loop and we'll never return control to Gdb. >> >> Therefore I have two questions: >> 1) Is this a bug? >> 2) If it is, what should the behaviour be? I think we should return >> control back to gdb, but we shouldn't try to translate that >> instruction again. How could we handle this in a clean way? >=20 > Our handling of exceptions and exception priorities for > Cortex-M CPUs is totally wrong. We attempt to reuse the > GIC priority handling code for interrupts, which then leaves > the exceptions without the correct priority handling. Ideally > we should rewrite this completely to give the M profile > cores the architecturally mandated exception priority > handling and masking, and stop trying to reuse the > A/R profile core code at all. The two profiles are just > too different for that to make sense. Are you saying we should dump the inheritence completely? Andreas >=20 > Any bugs or weirdness in the current code are likely > symptoms of attempting to shoehorn M profile into the > A/R profile handling. >=20 > -- PMM >=20 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg