All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pingfan Liu <kernelfans@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mark Rutland <mark.rutland@arm.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64/irq: report bug if NR_IPI greater than max SGI during compile time
Date: Tue, 8 Dec 2020 18:00:12 +0800	[thread overview]
Message-ID: <CAFgQCTtWhZoTyCP1ByrAhHrkWX=V49pQjPYeLVvv=bhT63Ekmw@mail.gmail.com> (raw)
In-Reply-To: <867be4df47247f8c56687cf2046ee7bb@kernel.org>

On Tue, Dec 8, 2020 at 5:51 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On 2020-12-08 09:43, Pingfan Liu wrote:
> > On Tue, Dec 8, 2020 at 5:31 PM Marc Zyngier <maz@kernel.org> wrote:
> >>
> >> On 2020-12-08 09:21, Pingfan Liu wrote:
> >> > Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had
> >> > better
> >> > do the check during built time, and associate these related code
> >> > together.
> >> >
> >> > Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
> >> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> > Cc: Will Deacon <will@kernel.org>
> >> > Cc: Thomas Gleixner <tglx@linutronix.de>
> >> > Cc: Jason Cooper <jason@lakedaemon.net>
> >> > Cc: Marc Zyngier <maz@kernel.org>
> >> > Cc: Mark Rutland <mark.rutland@arm.com>
> >> > To: linux-arm-kernel@lists.infradead.org
> >> > Cc: linux-kernel@vger.kernel.org
> >> > ---
> >> >  arch/arm64/kernel/smp.c                | 2 ++
> >> >  drivers/irqchip/irq-gic-v3.c           | 2 +-
> >> >  drivers/irqchip/irq-gic.c              | 2 +-
> >> >  include/linux/irqchip/arm-gic-common.h | 2 ++
> >> >  4 files changed, 6 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> >> > index 18e9727..9fc383c 100644
> >> > --- a/arch/arm64/kernel/smp.c
> >> > +++ b/arch/arm64/kernel/smp.c
> >> > @@ -33,6 +33,7 @@
> >> >  #include <linux/kernel_stat.h>
> >> >  #include <linux/kexec.h>
> >> >  #include <linux/kvm_host.h>
> >> > +#include <linux/irqchip/arm-gic-common.h>
> >> >
> >> >  #include <asm/alternative.h>
> >> >  #include <asm/atomic.h>
> >> > @@ -76,6 +77,7 @@ enum ipi_msg_type {
> >> >       IPI_WAKEUP,
> >> >       NR_IPI
> >> >  };
> >> > +static_assert(NR_IPI <= MAX_SGI_NUM);
> >>
> >> I am trying *very hard* to remove dependencies between the
> >> architecture
> >> code and random drivers, so this kind of check really is
> >> counter-productive.
> >>
> >> Driver code should not have to know the number of IPIs, because there
> >> is
> >> no requirement that all IPIs should map 1:1 to SGIs. Conflating the
> >> two
> >
> > Just curious about this. Is there an IPI which is not implemented by
> > SGI? Or mapping several IPIs to a single SGI, and scatter out due to a
> > global variable value?
>
> We currently have a single NS SGI left, and I'd like to move some of the
> non-critical IPIs over to dispatching mechanism (the two "CPU stop" IPIs
> definitely are candidate for merging). That's not implemented yet, but
> I don't see a need to add checks that would otherwise violate this
> IPI/SGI distinction.

Got it. Thanks for your detailed explanation.

Regards,
Pingfan

WARNING: multiple messages have this Message-ID (diff)
From: Pingfan Liu <kernelfans@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64/irq: report bug if NR_IPI greater than max SGI during compile time
Date: Tue, 8 Dec 2020 18:00:12 +0800	[thread overview]
Message-ID: <CAFgQCTtWhZoTyCP1ByrAhHrkWX=V49pQjPYeLVvv=bhT63Ekmw@mail.gmail.com> (raw)
In-Reply-To: <867be4df47247f8c56687cf2046ee7bb@kernel.org>

On Tue, Dec 8, 2020 at 5:51 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On 2020-12-08 09:43, Pingfan Liu wrote:
> > On Tue, Dec 8, 2020 at 5:31 PM Marc Zyngier <maz@kernel.org> wrote:
> >>
> >> On 2020-12-08 09:21, Pingfan Liu wrote:
> >> > Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had
> >> > better
> >> > do the check during built time, and associate these related code
> >> > together.
> >> >
> >> > Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
> >> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> > Cc: Will Deacon <will@kernel.org>
> >> > Cc: Thomas Gleixner <tglx@linutronix.de>
> >> > Cc: Jason Cooper <jason@lakedaemon.net>
> >> > Cc: Marc Zyngier <maz@kernel.org>
> >> > Cc: Mark Rutland <mark.rutland@arm.com>
> >> > To: linux-arm-kernel@lists.infradead.org
> >> > Cc: linux-kernel@vger.kernel.org
> >> > ---
> >> >  arch/arm64/kernel/smp.c                | 2 ++
> >> >  drivers/irqchip/irq-gic-v3.c           | 2 +-
> >> >  drivers/irqchip/irq-gic.c              | 2 +-
> >> >  include/linux/irqchip/arm-gic-common.h | 2 ++
> >> >  4 files changed, 6 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> >> > index 18e9727..9fc383c 100644
> >> > --- a/arch/arm64/kernel/smp.c
> >> > +++ b/arch/arm64/kernel/smp.c
> >> > @@ -33,6 +33,7 @@
> >> >  #include <linux/kernel_stat.h>
> >> >  #include <linux/kexec.h>
> >> >  #include <linux/kvm_host.h>
> >> > +#include <linux/irqchip/arm-gic-common.h>
> >> >
> >> >  #include <asm/alternative.h>
> >> >  #include <asm/atomic.h>
> >> > @@ -76,6 +77,7 @@ enum ipi_msg_type {
> >> >       IPI_WAKEUP,
> >> >       NR_IPI
> >> >  };
> >> > +static_assert(NR_IPI <= MAX_SGI_NUM);
> >>
> >> I am trying *very hard* to remove dependencies between the
> >> architecture
> >> code and random drivers, so this kind of check really is
> >> counter-productive.
> >>
> >> Driver code should not have to know the number of IPIs, because there
> >> is
> >> no requirement that all IPIs should map 1:1 to SGIs. Conflating the
> >> two
> >
> > Just curious about this. Is there an IPI which is not implemented by
> > SGI? Or mapping several IPIs to a single SGI, and scatter out due to a
> > global variable value?
>
> We currently have a single NS SGI left, and I'd like to move some of the
> non-critical IPIs over to dispatching mechanism (the two "CPU stop" IPIs
> definitely are candidate for merging). That's not implemented yet, but
> I don't see a need to add checks that would otherwise violate this
> IPI/SGI distinction.

Got it. Thanks for your detailed explanation.

Regards,
Pingfan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-12-08 10:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08  9:21 [PATCH] arm64/irq: report bug if NR_IPI greater than max SGI during compile time Pingfan Liu
2020-12-08  9:21 ` Pingfan Liu
2020-12-08  9:31 ` Marc Zyngier
2020-12-08  9:31   ` Marc Zyngier
2020-12-08  9:43   ` Pingfan Liu
2020-12-08  9:43     ` Pingfan Liu
2020-12-08  9:51     ` Marc Zyngier
2020-12-08  9:51       ` Marc Zyngier
2020-12-08 10:00       ` Pingfan Liu [this message]
2020-12-08 10:00         ` Pingfan Liu

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='CAFgQCTtWhZoTyCP1ByrAhHrkWX=V49pQjPYeLVvv=bhT63Ekmw@mail.gmail.com' \
    --to=kernelfans@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.