[Q] zynqmp-ipi-mailbox and SGI interrupts

[Q] zynqmp-ipi-mailbox and SGI interrupts

[Sebastian Andrzej Siewior]

Hi,

The ZynqMP IPI Mailbox driver supports two bindings of which
xlnx,versal-ipi-mailbox is not present in any kernel dts file and
xlnx,zynqmp-ipi-mailbox is used in two .dtsi files.
For the per-CPU interrupts the irq-type should be 2 (which would
correspond with GIC_ESPI in the dts, no?) which I can't find.
Before the IPI_IRQ_TYPE_SGI it used to check for the value less than 16
I also can't find this in the two available dts file.
I did browse over the "AMD Versal Virt" but it also looks not present.

My question is whether this is used or just a development step that
never got somewhere. 
My guess is that the device tree here is preconfigured from the boot
firmware.
So is this SGI-IPI a thing or not?

Sebastian

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

[Shah, Tanmay]

Hello,

Thank you for your email, please find my response below:

On 10/15/2026 3:39 AM, Sebastian Andrzej Siewior wrote:
> Hi,
> 
> The ZynqMP IPI Mailbox driver supports two bindings of which
> xlnx,versal-ipi-mailbox is not present in any kernel dts file and

This new bindings are for Versal and later SoCs which has buffer-less
IPI. It supports only notification to the other core without any data
transfer. The device-tree nodes may not be available in the upstream
kernel yet, but it is used by other consumers. Here is an example:

https://github.com/Xilinx/u-boot-xlnx/blob/master/arch/arm/dts/versal-net-vn-x-b2197-01-revA.dts#L100


> xlnx,zynqmp-ipi-mailbox is used in two .dtsi files.
> For the per-CPU interrupts the irq-type should be 2 (which would
> correspond with GIC_ESPI in the dts, no?) which I can't find.
> Before the IPI_IRQ_TYPE_SGI it used to check for the value less than 16
> I also can't find this in the two available dts file.
> I did browse over the "AMD Versal Virt" but it also looks not present.
> 
> My question is whether this is used or just a development step that
> never got somewhere. 

No, it is the actual use case supported by the driver. Just the
device-tree node is not in the upstream kernel, because it is usually
project/vendor/consumer specific.

> My guess is that the device tree here is preconfigured from the boot
> firmware.

Yes.

> So is this SGI-IPI a thing or not?
> 

Yes it is. Ideally, TF-A and Linux can share the IPI. If the IPI
interrupt is used by the TF-A and the expectation is that Linux mailbox
work on the same IPI (because all other IPIs are busy) then the work
around is, TF-A will generate SGI for the linux mbox driver, and the
mbox driver will use that SGI via device-tree.

It is a vendor specific use case. So the dt-node for this use case, may
not be available in the usptream kernel, but can be enabled if correct
SGI is configured via the device-tree.

Thank you,
Tanmay

> Sebastian

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

[Sebastian Andrzej Siewior]

On 2026-10-16 11:10:29 [-0500], Shah, Tanmay wrote:
> Hello,
Hello,

> Thank you for your email, please find my response below:

Thank you for your email, too.

> > So is this SGI-IPI a thing or not?
> > 
> 
> Yes it is. Ideally, TF-A and Linux can share the IPI. If the IPI
> interrupt is used by the TF-A and the expectation is that Linux mailbox
> work on the same IPI (because all other IPIs are busy) then the work
> around is, TF-A will generate SGI for the linux mbox driver, and the
> mbox driver will use that SGI via device-tree.
> 
> It is a vendor specific use case. So the dt-node for this use case, may
> not be available in the usptream kernel, but can be enabled if correct
> SGI is configured via the device-tree.

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?

> Thank you,
> Tanmay
> 
Sebastian

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

[Shah, Tanmay]

On 10/16/2026 11:23 AM, Sebastian Andrzej Siewior wrote:
> On 2026-10-16 11:10:29 [-0500], Shah, Tanmay wrote:
>> Hello,
> Hello,
> 
>> Thank you for your email, please find my response below:
> 
> Thank you for your email, too.
> 
>>> So is this SGI-IPI a thing or not?
>>>
>>
>> Yes it is. Ideally, TF-A and Linux can share the IPI. If the IPI
>> interrupt is used by the TF-A and the expectation is that Linux mailbox
>> work on the same IPI (because all other IPIs are busy) then the work
>> around is, TF-A will generate SGI for the linux mbox driver, and the
>> mbox driver will use that SGI via device-tree.
>>
>> It is a vendor specific use case. So the dt-node for this use case, may
>> not be available in the usptream kernel, but can be enabled if correct
>> SGI is configured via the device-tree.
> 
> 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.

Driver access those registers via percpu APIs, for example:
xlnx_mbox_cpuhp_start() uses enable_percpu_irq(). It is called for each CPU.

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

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

[Sebastian Andrzej Siewior]

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.

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.

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

> >> Thank you,
> >> Tanmay

Sebastian

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