From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAdoq-0001a0-Kr for qemu-devel@nongnu.org; Thu, 02 Jul 2015 08:42:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAdol-0002BB-He for qemu-devel@nongnu.org; Thu, 02 Jul 2015 08:42:20 -0400 Received: from mail-vn0-f42.google.com ([209.85.216.42]:34836) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAdol-0002B6-EA for qemu-devel@nongnu.org; Thu, 02 Jul 2015 08:42:15 -0400 Received: by vnbg190 with SMTP id g190so11138860vnb.2 for ; Thu, 02 Jul 2015 05:42:14 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1435669649-3035-1-git-send-email-peter.maydell@linaro.org> <1435669649-3035-4-git-send-email-peter.maydell@linaro.org> From: Peter Maydell Date: Thu, 2 Jul 2015 13:41:55 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 3/5] hw/arm/boot: Configure secure GIC to make IRQs NS if booting an NS kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: "Edgar E. Iglesias" , "qemu-devel@nongnu.org Developers" , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Patch Tracking On 30 June 2015 at 21:10, Peter Crosthwaite wrote: > On Tue, Jun 30, 2015 at 12:42 PM, Peter Maydell > wrote: >> On 30 June 2015 at 20:01, Peter Crosthwaite >> wrote: >>> So I actually had my own patches for this one that went in a different >>> direction. The reason is, there are also other devs out there which >>> need post-firmware state setup. The one I an thinking of mainly is the >>> Zynq SLCR setup for non-firmware boots, I.E. the Linux kernel expects >>> firmware to setup devices to some sort of initialized state (mainly >>> turning clocks on). I think this GIC setup falls in the same category. >>> The third use case is the GIC_CPU_IF stuff currently managed by >>> machine code in boot.c that could be outsourced to GIC (in either a >>> similar way to what is done here, or more fully outsourced using my >>> new API). >> >> I'm a bit torn here -- I don't want to make it *too* easy for >> people to add linux-booting specific code to random devices, >> as this will lead to the bootloader code having its tentacles >> everywhere within the tree... So I thought about this a bit, and I guess that having a general interface is probably better than specifically setting a GIC property. It does need to be called once at arm_kernel_load_notify time, not as a reset hook. I also think it should pass in the arm_boot_info* as a parameter. This would let the GIC do the right thing based on whether we're booting S or NS. Are you planning to respin this patchset, or should I just pull the relevant bits into my series? thanks -- PMM