[BOOTWRAPPER PATCH 2/2] Add support for GICv5

[Sascha Bischoff]

On Fri, 2026-02-27 at 14:47 +0000, Vladimir Murzin wrote:
> 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?

I think that the S/RL_DB_PPIs could be omitted without major issues.
Software might try and register some handlers for them, but they will
never fire under bootwrapper, although attempts to enable them would
fail (RAZ/WI), which might one day trip up some software.

To quote software usage guidance S_FKVPW from the GICv5 EAC0 spec [1]:

"When the Current Physical Interrupt Domain is a Non-EL3 Interrupt
Domain, if a Doorbell PPI for another Non-EL3 Interrupt Domain is
implemented, it must be assigned to the Current Physical Interrupt
Domain so that it can be signaled and handled in the Current Physical
Interrupt Domain."

I think it all depends on the illusion we want to provide to NS SW. If
it can see the S/RL_PPI_DBs, it can use them to deduce that other
worlds exist, even if nothing is running there. Does that matter?

For the SW_PPI, I guess it is a similar story in that it can't be
driven by software in a different world. However, it could arguably be
(ab)used by two bits of NS software to communicate. Ew, I know. In the
end, it is there for software to use in whatever way it wants, so it
might be best to just assign this one to NS too.

Under KVM, we're letting a guest see the (virtual) SW_PPI - although we
do allow the userspace VMM to drive that, should it choose to.

In both cases, we could do it later if needed, but I figure we might as
well do it now unless there's a good reason not to. Do say if there is,
please!

Sascha

[1] https://developer.arm.com/documentation/aes0070/latest/

> 
> Vladimir
> 
> > Sascha
>