Re: Query about IPI as NMI (pseudo-NMI) support patches

[Mukesh Ojha]

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@xxxxxxxxxxx> 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@xxxxxxxxxxx> wrote:
> > > > > Hi Marc,
> > > > >
> > > > > I was looking similar support mentioned in below patch series.
> > > > >
> > > > > https://lore.kernel.org/lkml/CAFA6WYO0+LQ=mB1spCstt0cNZ0G+sZu_+Wrv6BKSeXqF5SRq4A@xxxxxxxxxxxxxx/#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@xxxxxxxxxx/ 
> > >
> > >
> > >
> > >
> > > 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