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
Date: Tue, 03 Jan 2023 17:45:43 +0000 [thread overview]
Message-ID: <86v8ln7bqw.wl-maz@kernel.org> (raw)
In-Reply-To: <a20a9592-05e7-c529-5ab1-d7d52fffa59a@quicinc.com>
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.
next prev parent reply other threads:[~2023-01-03 17:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2023-01-04 15:49 ` Mukesh Ojha
2023-01-19 16:42 ` Mukesh Ojha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86v8ln7bqw.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_mojha@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox