From: Marc Zyngier <maz@kernel.org>
To: Chen-Yu Tsai <wenst@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Alexandru Elisei <Alexandru.Elisei@arm.com>
Subject: Re: [PATCH] irqchip/gic-v3: Fix priority comparison when non-secure priorities are used
Date: Wed, 11 Aug 2021 19:31:36 +0100 [thread overview]
Message-ID: <87fsvfal4n.wl-maz@kernel.org> (raw)
In-Reply-To: <20210811171505.1502090-1-wenst@chromium.org>
+ Alex, who introduced this.
On Wed, 11 Aug 2021 18:15:05 +0100,
Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> When non-secure priorities are used, compared to the raw priority set,
> the value read back from RPR is also right-shifted by one and the
> highest bit set.
>
> Add a macro to do the modifications to the raw priority when doing the
> comparison against the RPR value. This corrects the pseudo-NMI behavior
> when non-secure priorities in the GIC are used. Tested on 5.10 with
> the "IPI as pseudo-NMI" series [1] applied on MT8195.
>
> [1] https://lore.kernel.org/linux-arm-kernel/1604317487-14543-1-git-send-email-sumit.garg@linaro.org/
>
> Fixes: 336780590990 ("irqchip/gic-v3: Support pseudo-NMIs when SCR_EL3.FIQ == 0")
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> drivers/irqchip/irq-gic-v3.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index e0f4debe64e1..e7a0b55413db 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -100,6 +100,15 @@ EXPORT_SYMBOL(gic_pmr_sync);
> DEFINE_STATIC_KEY_FALSE(gic_nonsecure_priorities);
> EXPORT_SYMBOL(gic_nonsecure_priorities);
>
> +#define GICD_INT_RPR_PRI(priority) \
> + ({ \
> + u32 __priority = (priority); \
> + if (static_branch_unlikely(&gic_nonsecure_priorities)) \
> + __priority = 0x80 | (__priority >> 1); \
> + \
> + __priority; \
This doesn't reflect what the pseudocode says of a read of ICC_RPR_EL1
AFAICS. When the priority is activated, it is indeed shifted. But a
read of RPR does appear to shift things back (and you loose the lowest
bit in the process). Please see 'aarch64/support/ICC_RPR_EL1' in the
architecture spec.
Can you confirm that SCR_EL3.FIQ is set on your system?
Thanks,
M.
> + })
> +
> /* ppi_nmi_refs[n] == number of cpus having ppi[n + 16] set as NMI */
> static refcount_t *ppi_nmi_refs;
>
> @@ -687,7 +696,7 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
> return;
>
> if (gic_supports_nmi() &&
> - unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
> + unlikely(gic_read_rpr() == GICD_INT_RPR_PRI(GICD_INT_NMI_PRI))) {
> gic_handle_nmi(irqnr, regs);
> return;
> }
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Chen-Yu Tsai <wenst@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Alexandru Elisei <Alexandru.Elisei@arm.com>
Subject: Re: [PATCH] irqchip/gic-v3: Fix priority comparison when non-secure priorities are used
Date: Wed, 11 Aug 2021 19:31:36 +0100 [thread overview]
Message-ID: <87fsvfal4n.wl-maz@kernel.org> (raw)
In-Reply-To: <20210811171505.1502090-1-wenst@chromium.org>
+ Alex, who introduced this.
On Wed, 11 Aug 2021 18:15:05 +0100,
Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> When non-secure priorities are used, compared to the raw priority set,
> the value read back from RPR is also right-shifted by one and the
> highest bit set.
>
> Add a macro to do the modifications to the raw priority when doing the
> comparison against the RPR value. This corrects the pseudo-NMI behavior
> when non-secure priorities in the GIC are used. Tested on 5.10 with
> the "IPI as pseudo-NMI" series [1] applied on MT8195.
>
> [1] https://lore.kernel.org/linux-arm-kernel/1604317487-14543-1-git-send-email-sumit.garg@linaro.org/
>
> Fixes: 336780590990 ("irqchip/gic-v3: Support pseudo-NMIs when SCR_EL3.FIQ == 0")
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> drivers/irqchip/irq-gic-v3.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index e0f4debe64e1..e7a0b55413db 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -100,6 +100,15 @@ EXPORT_SYMBOL(gic_pmr_sync);
> DEFINE_STATIC_KEY_FALSE(gic_nonsecure_priorities);
> EXPORT_SYMBOL(gic_nonsecure_priorities);
>
> +#define GICD_INT_RPR_PRI(priority) \
> + ({ \
> + u32 __priority = (priority); \
> + if (static_branch_unlikely(&gic_nonsecure_priorities)) \
> + __priority = 0x80 | (__priority >> 1); \
> + \
> + __priority; \
This doesn't reflect what the pseudocode says of a read of ICC_RPR_EL1
AFAICS. When the priority is activated, it is indeed shifted. But a
read of RPR does appear to shift things back (and you loose the lowest
bit in the process). Please see 'aarch64/support/ICC_RPR_EL1' in the
architecture spec.
Can you confirm that SCR_EL3.FIQ is set on your system?
Thanks,
M.
> + })
> +
> /* ppi_nmi_refs[n] == number of cpus having ppi[n + 16] set as NMI */
> static refcount_t *ppi_nmi_refs;
>
> @@ -687,7 +696,7 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
> return;
>
> if (gic_supports_nmi() &&
> - unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
> + unlikely(gic_read_rpr() == GICD_INT_RPR_PRI(GICD_INT_NMI_PRI))) {
> gic_handle_nmi(irqnr, regs);
> return;
> }
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2021-08-11 18:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-11 17:15 [PATCH] irqchip/gic-v3: Fix priority comparison when non-secure priorities are used Chen-Yu Tsai
2021-08-11 17:15 ` Chen-Yu Tsai
2021-08-11 18:31 ` Marc Zyngier [this message]
2021-08-11 18:31 ` Marc Zyngier
2021-08-12 11:51 ` Alexandru Elisei
2021-08-12 11:51 ` Alexandru Elisei
2021-08-12 13:09 ` Marc Zyngier
2021-08-12 13:09 ` Marc Zyngier
2021-08-12 14:24 ` Alexandru Elisei
2021-08-12 14:24 ` Alexandru Elisei
2021-08-20 12:58 ` Marc Zyngier
2021-08-20 12:58 ` Marc Zyngier
2021-08-16 15:11 ` Chen-Yu Tsai
2021-08-16 15:11 ` Chen-Yu Tsai
2021-08-20 13:31 ` Alexandru Elisei
2021-08-20 13:31 ` Alexandru Elisei
2021-08-20 13:55 ` Marc Zyngier
2021-08-20 13:55 ` Marc Zyngier
2021-08-20 13:34 ` [irqchip: irq/irqchip-next] " irqchip-bot for Chen-Yu Tsai
2021-08-20 14:05 ` irqchip-bot for Chen-Yu Tsai
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=87fsvfal4n.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Alexandru.Elisei@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=wenst@chromium.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.