Re: [Q] zynqmp-ipi-mailbox and SGI interrupts

[Shah, Tanmay]

On 10/16/2026 12:10 PM, Sebastian Andrzej Siewior wrote:
> On 2026-10-16 11:44:07 [-0500], Shah, Tanmay wrote:
>>> And it has to be a per-CPU interrupt? It can't become a regular
>>> interrupt which is not per-CPU? Does the driver at some point access
>>> per-CPU registers?
>>>
>>
>> As per my understanding, it has to be a per-CPU interrupt.
> 
> I see.
> 
>> Driver access those registers via percpu APIs, for example:
>> xlnx_mbox_cpuhp_start() uses enable_percpu_irq(). It is called for each CPU.
> 
> Yes I know that part but this is not the question.
> 
> I meant _why_ the interrupt has to be per-CPU. I'm not sure if this is
> internal wired as such or just configured.
> 

I think the SGI is configured that way in the driver. Probably at the
implementation time couldn't find the better way.

> For instance a timer is using a per-CPU interrupt. While the timer is
> programmed for the next expiry it uses per-CPU registers. So the timer
> accessed from CPU0 is different than the one accessed from CPU1. Once
> the interrupt fires, the processing that follows is different on both
> CPUs.
> 
> Looking through zynqmp_sgi_interrupt() which just invokes
> zynqmp_ipi_interrupt() I don't see the difference. The OP-TEE firmware
> is invoked at least the bits I saw, it just masks the source and moves
> on. So I am not sure what is the difference between the interrupt on
> CPU0 vs CPU1. Both could fire at the same time and handle the same
> request unless the firmware returns a different
> IPI_MB_STATUS_RECV_PENDING bit. I don't see how the remote side would
> make a difference between those two CPUs.
> 

There is no difference between the interrupt on CPU0 vs CPU1. The CPU
affinity is decided by the TF-A when configuring the SGI. The driver has
just lazy implementation where it doesn't check for the SGI's CPU
affinity before configuring it and will assume that SGI can happen for
any CPU. The driver can be improved to find out SGI's CPU affinity and
request SGI only for that particular CPU. But current implementation is
not optimized that way.

I am not expert in the GIC interrupt handling of SGI, but I think your
question is valid. The answer IMHO is the driver's implementation might
not be the most optimized.

Thank you,
Tanmay

> So this is what I am wondering about. Based on your response so far this
> has to be that way.
> 

>>>> Thank you,
>>>> Tanmay
> 
> Sebastian