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;
Date:   Tue, 03 Jan 2023 17:45:43 +0000
Message-ID: <86v8ln7bqw.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     Mukesh Ojha <quic_mojha@quicinc.com>
Cc:     lkml <linux-kernel@vger.kernel.org>
Subject: Re: Query about IPI as NMI (pseudo-NMI) support patches
In-Reply-To: <a20a9592-05e7-c529-5ab1-d7d52fffa59a@quicinc.com>
References: <5bed08c5-8663-4e68-27b4-8b6d3957a880@quicinc.com>
        <86zgb07tfs.wl-maz@kernel.org>
        <a20a9592-05e7-c529-5ab1-d7d52fffa59a@quicinc.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2
 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

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.