Hi Julien/Mykola, > On 2 Dec 2025, at 19:26, Julien Grall <[email protected]> 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 <[email protected]> wrote: >>>> Signed-off-by: Mykola Kvach <[email protected]> >>>> --- >>>> 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
