From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiiwB-0002ku-Ua for qemu-devel@nongnu.org; Mon, 27 Oct 2014 07:58:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xiiw7-0002R5-4f for qemu-devel@nongnu.org; Mon, 27 Oct 2014 07:58:15 -0400 Received: from mail-lb0-f176.google.com ([209.85.217.176]:47844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xiiw6-0002Qn-Ub for qemu-devel@nongnu.org; Mon, 27 Oct 2014 07:58:11 -0400 Received: by mail-lb0-f176.google.com with SMTP id p9so5453357lbv.7 for ; Mon, 27 Oct 2014 04:58:09 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1413910544-20150-1-git-send-email-greg.bellows@linaro.org> <1413910544-20150-8-git-send-email-greg.bellows@linaro.org> From: Peter Maydell Date: Mon, 27 Oct 2014 11:57:49 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v7 07/32] target-arm: extend async excp masking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Bellows Cc: Sergey Fedorov , QEMU Developers , Fabian Aggeler , "Edgar E. Iglesias" On 26 October 2014 22:30, Peter Maydell wrote: > In fact, since all of the "exception is not taken" cases are for > "we are in secure EL3 and the exception is not being routed to > secure EL3" you could just make all those entries read "1" and > rely on the "target_el < current_el" check. That does slightly > harm readability though. Thinking further about this I actually prefer it -- it completely separates routing from masking. So you should make those entries read '1' and then just use -1 for "not possible" (and assert that the table lookup never gives you -1). > I looked through the tables for the AArch32 routing, and I can't > see anywhere where they're different from the AArch64 routing > handling. [...] Did I miss something? I did! If EL3 is AArch32 and the SCR.FIQ etc bits are clear then the FIQ/IRQ in the secure world target EL3, not EL1 (since the latter doesn't exist). We can handle that by using the AArch64 table anyway and just having a bit at the end that says "if we're secure and target_el is 1 then set it to 3", or if you prefer with a second table. -- PMM