Date:   Thu, 24 Oct 2019 09:27:08 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        <bcm-kernel-feedback-list@...adcom.com>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        Souvik Chakravarty <souvik.chakravarty@....com>,
        Jim Quinlan <james.quinlan@...adcom.com>,
        Sudeep Holla <sudeep.holla@....com>,
        Thanu Rangarajan <thanu.rangarajan@....com>
Subject: Re: [PATCH RFC 2/2] irqchip/gic: Allow the use of SGI interrupts

On 2019-10-23 18:02, Florian Fainelli wrote:
> Hello marc,
>
> On 10/23/19 6:22 AM, Marc Zyngier wrote:
>> Hi Florian,
>>
>> Needless to say, I mostly have questions...
>>
>> On 2019-10-23 01:05, Florian Fainelli wrote:
>>> SGI interrupts are a convenient way for trusted firmware to target 
>>> a
>>> specific set of CPUs. Update the ARM GIC code to allow the 
>>> translation
>>> and mapping of SGI interrupts.
>>>
>>> Since the kernel already uses SGIs for various inter-processor 
>>> interrupt
>>> activities, we specifically make sure that we do not let users of 
>>> the
>>> IRQ API to even try to map those.
>>>
>>> Internal IPIs remain dispatched through handle_IPI() while public 
>>> SGIs
>>> get promoted to a normal interrupt flow management.
>>>
>>> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
>>> ---
>>>  drivers/irqchip/irq-gic.c | 41 
>>> +++++++++++++++++++++++++++------------
>>>  1 file changed, 29 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>>> index 30ab623343d3..dcfdbaacdd64 100644
>>> --- a/drivers/irqchip/irq-gic.c
>>> +++ b/drivers/irqchip/irq-gic.c
>>> @@ -385,7 +385,10 @@ static void __exception_irq_entry
>>> gic_handle_irq(struct pt_regs *regs)
>>>               * Pairs with the write barrier in gic_raise_softirq
>>>               */
>>>              smp_rmb();
>>> -            handle_IPI(irqnr, regs);
>>> +            if (irqnr < NR_IPI)
>>> +                handle_IPI(irqnr, regs);
>>> +            else
>>> +                handle_domain_irq(gic->domain, irqnr, regs);
>>
>> Double EOI, UNPREDICTABLE territory, your state machine is now dead.
>
> Oh yes, the interrupt flow now also goes through ->irq_eoi (that's 
> the
> whole point), meh.

Indeed. But to be honest, we should probably consider moving all the 
SGI
handling to normal interrupts. There's hardly any reason why we should 
keep
SGIs out of the normal interrupt model, other than maybe performance 
(and
that's pretty dubious).

>
>>
>>>  #endif
>>>              continue;
>>>          }
>>> @@ -1005,20 +1008,34 @@ static int gic_irq_domain_translate(struct
>>> irq_domain *d,
>>>          if (fwspec->param_count < 3)
>>>              return -EINVAL;
>>>
>>> -        /* Get the interrupt number and add 16 to skip over SGIs 
>>> */
>>> -        *hwirq = fwspec->param[1] + 16;
>>> -
>>> -        /*
>>> -         * For SPIs, we need to add 16 more to get the GIC irq
>>> -         * ID number
>>> -         */
>>> -        if (!fwspec->param[0])
>>> +        *hwirq = fwspec->param[1];
>>> +        switch (fwspec->param[0]) {
>>> +        case 0:
>>> +            /*
>>> +             * For SPIs, we need to add 16 more to get the GIC irq
>>> +             * ID number
>>> +             */
>>> +            *hwirq += 16;
>>> +            /* fall through */
>>> +        case 1:
>>> +            /* Add 16 to skip over SGIs */
>>>              *hwirq += 16;
>>> +            *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
>>>
>>> -        *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
>>> +            /* Make it clear that broken DTs are... broken */
>>> +            WARN_ON(*type == IRQ_TYPE_NONE);
>>> +            break;
>>> +        case 2:
>>> +            /* Refuse to map internal IPIs */
>>> +            if (*hwirq < NR_IPI)
>>
>> So depending on how the kernel uses SGIs, you can or cannot use 
>> these SGIs.
>> That looks like a good way to corner ourselves into not being to 
>> change
>> much.
>
> arch/arm/kernel/smp.c has a forward looking statement about SGI 
> numbering:
>
>         /*
>          * SGI8-15 can be reserved by secure firmware, and thus may
>          * not be usable by the kernel. Please keep the above limited
>          * to at most 8 entries.
>          */
>
> is this something that can be used as an universal and unbreakable 
> rule
> for the ARM64 kernel as well in order to ensure SGIs 8-15 can be 
> usable
> through the IRQ API or is this simply not a guarantee at all?

There is no guarantee whatsoever. There's an ARM recommendation about 
the
above split, but that's it. Hardly something that can be enforced.

Now, your firmware is the one that gives you the DT, so if it is 
inconsistent
in configuring the interrupt and presenting it to the kernel, tough 
luck.

>> Also, do you expect this to work for both Group-0 and Group-1 
>> interrupts
>> (since you imply that this works as a communication medium with the 
>> secure
>> side)? Given that the kernel running in NS has no way to 
>> enable/disable
>> Group-0 interrupts, this looks terminally flawed. Or is that Group-1 
>> only?
>
> That would be Group-1 interrupts only, are you suggesting there is an
> additional check being done that such SGIs are actually part of 
> Group-1?

You can try and change the configuration of that interrupt (priority, 
for
example), and see if that sticks. If it doesn't, you're in trouble (and
nothing you can do about it).

>>
>> How do we describe which SGIs are guaranteed to be available to 
>> Linux?
>
> In our case, the Device Tree mailbox node gets populated its 
> interrupts
> property with the SGI number(s), and that same number is also passed 
> as
> a configuration parameter to the trusted firmware. Or are you echoing
> back to your earlier comment about the fact that if the kernel 
> changes
> its own definition of NR_IPI then we suddenly start breaking IRQ API
> uses of SGIs in a certain range?

That's indeed my worry. There is also the fact that the kernel itself 
will
never expose such reservation in DT, so we'd have to tread carefully 
here.
We probably need to specify that *only* SGI8-15 are allowed to be 
described
as such.

Another thing: why don't you use a PPI? If you use a GICv2, you're also 
using
ancient cores, and they have PPIs to spare. Or do you rely on being 
able to
inject interrupts from one core to another?

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists