Re: [PATCH] xen/arm: irq: Use appropriate priority for SGIs in setup_irq()

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Julien/Mykola,

> On 2 Dec 2025, at 19:26, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi,
> 
> Sorry for the late answer.
> 
> On 16/09/2025 11:19, Mykola Kvach wrote:
>> On Sat, Sep 13, 2025 at 1:01 AM Julien Grall <julien@xxxxxxx> wrote:
>>>> Signed-off-by: Mykola Kvach <mykola_kvach@xxxxxxxx>
>>>> ---
>>>>   xen/arch/arm/irq.c | 8 +++++++-
>>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>>>> index 02ca82c089..17c7ac92b5 100644
>>>> --- a/xen/arch/arm/irq.c
>>>> +++ b/xen/arch/arm/irq.c
>>>> @@ -397,7 +397,13 @@ int setup_irq(unsigned int irq, unsigned int 
>>>> irqflags, struct irqaction *new)
>>> AFAIK, we are not using setup_irq() to handle SGIs because they are all
>>> static and always enabled. Are you planning to handle dynamic SGIs? If
>>> yes, then can you provide more details?As far as I know, there can be at 
>>> least one “dynamic” SGI in Xen.
>> As far as I know, there is at least one “dynamic” SGI in Xen. For
>> example, see ffa_notif.c in the functions ffa_notif_init_interrupt
>> and ffa_notif_init, which handle initialization of such SGIs.
> 
> Bertrand can you comment on this? In particular, do we want the FFA SGIs to 
> have the priority of the internal ones?

The following is only an advice, definitely not a requirement. I would
be ok to ack the current way to do things as right now FF-A is unsupported and
is the only case of usage of dynamic SGI.
I would though require to have a log message to warn the user that SGI xx
has the same priority as xen internal interrupts during request_irq.

Here is what I think:

FFA SGIs can only be generated by the secure world and in practice they will
be generated mostly when coming coming back from the secure world (either
after a preemption or on a return to an smc call) but one could also be
generated from the secure world from another core, preempting whatever runs
(but same would occur when an interrupt is directly handled in the secure 
world).

Linux kernel implementation is not lowering the FF-A SGI interrupt as far as I 
know.

In my view having the FFA SGI having the same priority as ffa internal SGI 
would mean
we have some trust that the secure world will not overload us.

But in reality it would make sense to have a priority ordering like:
- Xen internal SGIs
- FF-A SGI (or any other dynamic SGI)
- any other kind of interrupt 

So that Xen internal SGIs have the highest priority, but having other SGIs 
still having
a better priority than other interrupts.

In any case, whatever we do, we should keep it possible to have one specific 
dynamic
SGI at the maximum level or even at an higher level (ie lower down xen internal 
SGIs)
for specific use cases (handling hardware errors comes to mind) but this is ok 
to make
this possible only by changing xen code or when creating such a specific driver.

Cheers
Bertrand