qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/5] hw/arm/boot: Configure secure GIC to make I


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 3/5] hw/arm/boot: Configure secure GIC to make IRQs NS if booting an NS kernel
Date: Thu, 2 Jul 2015 13:41:55 +0100

On 30 June 2015 at 21:10, Peter Crosthwaite
<address@hidden> wrote:
> On Tue, Jun 30, 2015 at 12:42 PM, Peter Maydell
> <address@hidden> wrote:
>> On 30 June 2015 at 20:01, Peter Crosthwaite
>> <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]