[BOOTWRAPPER PATCH 2/2] Add support for GICv5
Vladimir Murzin
vladimir.murzin at arm.com
Fri Feb 27 06:47:28 PST 2026
Hi Sascha,
On 2/27/26 14:24, Sascha Bischoff wrote:
> On Fri, 2026-02-27 at 11:19 +0000, Vladimir Murzin wrote:
>> Hi Joey!
>>
>> On 2/27/26 11:06, Joey Gouly wrote:
>>> Hi!
>>>
>> [snip]
>>
>>>> +
>>>> +static void gic_ppi_init(void) {
>>>> + uint64_t val = 0;
>>>> +
>>>> + val |= 1UL << (2 * 31); // Trace Buffer Unit
>>>> + val |= 1UL << (2 * 30); // EL1 Physical Timer
>>>> + val |= 1UL << (2 * 28); // Non-secure EL2 Virtual Timer
>>>> + val |= 1UL << (2 * 27); // EL1 Virtual Timer
>>>> + val |= 1UL << (2 * 26); // Non-secure EL2 Physical Timer
>>>> + val |= 1UL << (2 * 25); // GIC maintenance interrupt
>>>> + val |= 1UL << (2 * 24); // Generic CTI interrupt trigger
>>>> event
>>>> + val |= 1UL << (2 * 23); // PMU overflow interrupt
>>>> request
>>>> + val |= 1UL << (2 * 22); // Debug communication channel
>>>> + val |= 1UL << (2 * 21); // Profiling Buffer management
>>>> interrupt request
>>>> + val |= 1UL << (2 * 15); // Hardware accelerator for
>>>> cleaning Dirty state interrupt
>>> What about SW_PPI (3) and NS_DB_PPI (2)? Are the left out for a
>>> reason?
>>>
>> No reason, I just missed them. Thanks for catching that!
> Hi both,
>
> I don't fully agree here.
>
> I think that the SW_PPI should be assigned to NS - it is a sane default
> so that normal software can use it. There's no pre-defined use case for
> this PPI, so it is just used however software chooses to use it. A
> potential use case would be for software in the Secure world to poke NS
> to say that it has completed some task (FF-A does this sort of thing
> using a donated SGI on GICv3, but could use the GICv5 SW_PPI for this
> in the future). In this flow, it is assigned to NS, and EL3 makes it
> pending as part of the return to NS from S so that NS software receives
> the doorbell.
>
> The NS_DB_PPI shouldn't ever be assigned to NS - it is there to alert a
> non-NS domain to the fact that NS has pending interrupts. It should
> never get signalled when running in NS (NS doesn't need an interrupt to
> tell it that it has interrupts ;) ). It is a "Please switch to the NS
> domain when you get the opportunity" signal. Hence, the S_DB_PPI,
> RL_DB_PPI however should likely be assigned to NS, by default.
>
> The expectation with the DB_PPIs is that EL3 might change their domains
> as part of a world-switch. That is, all DB PPIs "belonging" to the non-
> target domain would be assigned to the target domain as part of
> transitioning via EL3.
>
> A sane default would be to assign the NS_DB_PPI to Secure.
>
> I hope that makes sense.
>
Thanks for such detailed explanation, really appreciate that! Bootwrapper
doesn't run services in Secure world, so perhaps we can leave things as
they are and add any additional PPIs on as needed basis.
What do you reckon?
Vladimir
> Sascha
More information about the linux-arm-kernel
mailing list