Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <97f8d450-8f1b-c89d-f0eb-813d17744975@quicinc.com>
Date:   Thu, 19 Jan 2023 22:12:12 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.1
Subject: Re: Query about IPI as NMI (pseudo-NMI) support patches
Content-Language: en-US
From:   Mukesh Ojha <quic_mojha@quicinc.com>
To:     Marc Zyngier <maz@kernel.org>
CC:     lkml <linux-kernel@vger.kernel.org>
References: <5bed08c5-8663-4e68-27b4-8b6d3957a880@quicinc.com>
 <86zgb07tfs.wl-maz@kernel.org>
 <a20a9592-05e7-c529-5ab1-d7d52fffa59a@quicinc.com>
 <86v8ln7bqw.wl-maz@kernel.org>
 <c40486a0-2e5f-bbdb-c93b-8740154fce78@quicinc.com>
In-Reply-To: <c40486a0-2e5f-bbdb-c93b-8740154fce78@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Marc,


On 1/4/2023 9:19 PM, Mukesh Ojha wrote:
> Hi Marc,
> 
> Thanks for your patience in replying queries
> 
> On 1/3/2023 11:15 PM, Marc Zyngier wrote:
>> On Tue, 03 Jan 2023 16:45:04 +0000,
>> Mukesh Ojha <quic_mojha@quicinc.com> wrote:
>>>
>>> Hi,
>>>
>>> Thanks for your reply.
>>>
>>> On 1/2/2023 10:41 PM, Marc Zyngier wrote:
>>>> Hi Mukesh,
>>>>
>>>> On Mon, 02 Jan 2023 16:44:59 +0000,
>>>> Mukesh Ojha <quic_mojha@quicinc.com> wrote:
>>>>>
>>>>> Hi Marc,
>>>>>
>>>>> I was looking similar support mentioned in below patch series.
>>>>>
>>>>> https://lore.kernel.org/lkml/CAFA6WYO0+LQ=mB1spCstt0cNZ0G+sZu_+Wrv6BKSeXqF5SRq4A@mail.gmail.com/#t 
>>>>>
>>>>>
>>>>> Wanted to check if there is chance of these patches to land in
>>>>> mainline ?
>>>>
>>>> I certainly have no intention to merge it as is, specially as there is
>>>> no good usage model for it other than "but think of debug!".
>>>>
>>>> We have exactly *one* SGI left. If we are going to lose it over such a
>>>> feature, I'd want a description of how we are going to share it
>>>> between potential users, and how we claw some currently used SGIs
>>>> back.
>>>
>>>
>>> But, looks like patch will fail if SGI is not available.
>>>
>>> https://lore.kernel.org/lkml/1604317487-14543-4-git-send-email-sumit.garg@linaro.org/ 
>>>
>>>
>>>
>>>
>>> set_smp_ipi_range(base_sgi, 8);
>>>
>>> +    if (n > nr_ipi)
>>> +        set_smp_dynamic_ipi(ipi_base + nr_ipi);
>>> +
>>>
>>> So, static SGI allocation still has higher priority than dynamic
>>> one.  Would you be accepting if we keep it under some
>>> CONFIG_ARM64_IPI_NMI_DEBUG ?
>>
>> But why should this thing have priority over other potential features?
>> As I said above, there are two requirements:
>>
>> - being able to share a single NMI SGI amongst multiple users
>>
>> - being able to free existing SGIs in case we absolutely need an SGI
>>    for some other purposes
>>
>> In both cases, this is about making the SGI space scale *beyond* the 8
>> possible interrupts that we have. This needs to be solved to get
>> something like this in.
> 
> Agree, we have shortage of SGI's, Will try to think if we can fix this.
> 
> However, I think IPI_CPU_STOP is something which can be used as an NMI, 
> As this will be used only(once) during panic()->send_smp_stop().
> 
> Can we do some special handling for IPI_CPU_STOP similar to pmu 
> interrupts like request it as NMI and fallback to normal irq if not 
> supported/on error ?

Can we do this ?

-Mukesh
> 
> 
>>
>> And I don't think hiding this behind an obscure "debug" configuration
>> option that will get abused with out of tree stuff is a good move.
>> Quite the opposite.
>>
> 
> Thanks, Make sense.
> 
>> Thanks,
>>
>>     M.
>>
> 
> -Mukesh