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 ?
Thanks,
-Mukesh
Hi Mukesh,
On Mon, 02 Jan 2023 16:44:59 +0000,
Mukesh Ojha <[email protected]> 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.
Until then, this is a proof of concept, and not much else.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
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 <[email protected]> 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/[email protected]/
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 ?
-Mukesh
>
> Until then, this is a proof of concept, and not much else.
>
> Thanks,
>
> M.
>
On Tue, 03 Jan 2023 16:45:04 +0000,
Mukesh Ojha <[email protected]> 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 <[email protected]> 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/[email protected]/
>
>
>
> 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.
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,
M.
--
Without deviation from the norm, progress is not possible.
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 <[email protected]> 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 <[email protected]> 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/[email protected]/
>>
>>
>>
>> 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 ?
>
> 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
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 <[email protected]> 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 <[email protected]> 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/[email protected]/
>>>
>>>
>>>
>>>
>>> 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