* Query about IPI as NMI (pseudo-NMI) support patches @ 2023-01-02 16:44 Mukesh Ojha 2023-01-02 17:11 ` Marc Zyngier 0 siblings, 1 reply; 6+ messages in thread From: Mukesh Ojha @ 2023-01-02 16:44 UTC (permalink / raw) To: Marc Zyngier; +Cc: lkml 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query about IPI as NMI (pseudo-NMI) support patches 2023-01-02 16:44 Query about IPI as NMI (pseudo-NMI) support patches Mukesh Ojha @ 2023-01-02 17:11 ` Marc Zyngier 2023-01-03 16:45 ` Mukesh Ojha 0 siblings, 1 reply; 6+ messages in thread From: Marc Zyngier @ 2023-01-02 17:11 UTC (permalink / raw) To: Mukesh Ojha; +Cc: lkml 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. Until then, this is a proof of concept, and not much else. Thanks, M. -- Without deviation from the norm, progress is not possible. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query about IPI as NMI (pseudo-NMI) support patches 2023-01-02 17:11 ` Marc Zyngier @ 2023-01-03 16:45 ` Mukesh Ojha 2023-01-03 17:45 ` Marc Zyngier 0 siblings, 1 reply; 6+ messages in thread From: Mukesh Ojha @ 2023-01-03 16:45 UTC (permalink / raw) To: Marc Zyngier; +Cc: lkml 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 ? -Mukesh > > Until then, this is a proof of concept, and not much else. > > Thanks, > > M. > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query about IPI as NMI (pseudo-NMI) support patches 2023-01-03 16:45 ` Mukesh Ojha @ 2023-01-03 17:45 ` Marc Zyngier 2023-01-04 15:49 ` Mukesh Ojha 0 siblings, 1 reply; 6+ messages in thread From: Marc Zyngier @ 2023-01-03 17:45 UTC (permalink / raw) To: Mukesh Ojha; +Cc: lkml 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. 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query about IPI as NMI (pseudo-NMI) support patches 2023-01-03 17:45 ` Marc Zyngier @ 2023-01-04 15:49 ` Mukesh Ojha 2023-01-19 16:42 ` Mukesh Ojha 0 siblings, 1 reply; 6+ messages in thread From: Mukesh Ojha @ 2023-01-04 15:49 UTC (permalink / raw) To: Marc Zyngier; +Cc: lkml 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 ? > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query about IPI as NMI (pseudo-NMI) support patches 2023-01-04 15:49 ` Mukesh Ojha @ 2023-01-19 16:42 ` Mukesh Ojha 0 siblings, 0 replies; 6+ messages in thread From: Mukesh Ojha @ 2023-01-19 16:42 UTC (permalink / raw) To: Marc Zyngier; +Cc: lkml 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-01-19 16:42 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-01-02 16:44 Query about IPI as NMI (pseudo-NMI) support patches Mukesh Ojha 2023-01-02 17:11 ` Marc Zyngier 2023-01-03 16:45 ` Mukesh Ojha 2023-01-03 17:45 ` Marc Zyngier 2023-01-04 15:49 ` Mukesh Ojha 2023-01-19 16:42 ` Mukesh Ojha
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox