All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Hanks Chen <hanks.chen@mediatek.com>,
	Cheng-Yuh.Wu@mediatek.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] irqchip/gic-v3: Workaround for GIC-700 erratum 2941627
Date: Tue, 04 Jul 2023 16:23:10 +0100	[thread overview]
Message-ID: <86sfa3wvj5.wl-maz@kernel.org> (raw)
In-Reply-To: <ZKQ3O5yL7WuRga0N@lpieralisi>

On Tue, 04 Jul 2023 16:14:03 +0100,
Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> 
> On Tue, Jul 04, 2023 at 03:44:50PM +0100, Marc Zyngier wrote:
> > Lorenzo,
> > 
> > On Tue, 04 Jul 2023 13:34:36 +0100,
> > Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> > > 
> > > +static bool gic_enable_quirk_arm64_2941627(void *data)
> > > +{
> > > +	/*
> > > +	 * If CPUidle is not enabled the erratum runtime
> > > +	 * conditions can't be hit, since that requires:
> > > +	 *
> > > +	 * - A core entering a deep power state with
> > > +	 *   the associated GIC redistributor asleep
> > > +	 *   and an IRQ active and pending targeted at it
> > > +	 * - A different core handling the IRQ and
> > > +	 *   related GIC operations at the same time
> > > +	 */
> > > +	if (!IS_ENABLED(CONFIG_CPU_IDLE))
> > > +		return false;
> > 
> > Could this still hit on a system that traps WFI to EL3 and uses this
> > as a way to enter a low-power mode?
> 
> That's a valid point, I have not thought about that. If there are set-ups
> where this is allowed (and I think it *is* architecturally allowed with
> EL3 saving/restoring context and entering a deep power state - if you
> asked I suspect you have something concrete in mind :)) this "optimization"
> must be removed since we can still hit the bug; that's what I shall do
> for v2.

I do not have a concrete example of anyone doing that, but the fact
that it is possible by the letter of the architecture makes me think
that *someone* out there must be inventive enough to do it.

So I'd rather take the safe option and *always* enable the workaround.
And then someone else can rock up and explain why they don't need it.

Thanks,

	M.

-- 
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: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Hanks Chen <hanks.chen@mediatek.com>,
	Cheng-Yuh.Wu@mediatek.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] irqchip/gic-v3: Workaround for GIC-700 erratum 2941627
Date: Tue, 04 Jul 2023 16:23:10 +0100	[thread overview]
Message-ID: <86sfa3wvj5.wl-maz@kernel.org> (raw)
In-Reply-To: <ZKQ3O5yL7WuRga0N@lpieralisi>

On Tue, 04 Jul 2023 16:14:03 +0100,
Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> 
> On Tue, Jul 04, 2023 at 03:44:50PM +0100, Marc Zyngier wrote:
> > Lorenzo,
> > 
> > On Tue, 04 Jul 2023 13:34:36 +0100,
> > Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> > > 
> > > +static bool gic_enable_quirk_arm64_2941627(void *data)
> > > +{
> > > +	/*
> > > +	 * If CPUidle is not enabled the erratum runtime
> > > +	 * conditions can't be hit, since that requires:
> > > +	 *
> > > +	 * - A core entering a deep power state with
> > > +	 *   the associated GIC redistributor asleep
> > > +	 *   and an IRQ active and pending targeted at it
> > > +	 * - A different core handling the IRQ and
> > > +	 *   related GIC operations at the same time
> > > +	 */
> > > +	if (!IS_ENABLED(CONFIG_CPU_IDLE))
> > > +		return false;
> > 
> > Could this still hit on a system that traps WFI to EL3 and uses this
> > as a way to enter a low-power mode?
> 
> That's a valid point, I have not thought about that. If there are set-ups
> where this is allowed (and I think it *is* architecturally allowed with
> EL3 saving/restoring context and entering a deep power state - if you
> asked I suspect you have something concrete in mind :)) this "optimization"
> must be removed since we can still hit the bug; that's what I shall do
> for v2.

I do not have a concrete example of anyone doing that, but the fact
that it is possible by the letter of the architecture makes me think
that *someone* out there must be inventive enough to do it.

So I'd rather take the safe option and *always* enable the workaround.
And then someone else can rock up and explain why they don't need it.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2023-07-04 15:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-04 12:34 [PATCH] irqchip/gic-v3: Workaround for GIC-700 erratum 2941627 Lorenzo Pieralisi
2023-07-04 12:34 ` Lorenzo Pieralisi
2023-07-04 14:44 ` Marc Zyngier
2023-07-04 14:44   ` Marc Zyngier
2023-07-04 15:14   ` Lorenzo Pieralisi
2023-07-04 15:14     ` Lorenzo Pieralisi
2023-07-04 15:23     ` Marc Zyngier [this message]
2023-07-04 15:23       ` Marc Zyngier
2023-07-04 15:27   ` Lorenzo Pieralisi
2023-07-04 15:27     ` Lorenzo Pieralisi
2023-07-04 15:31     ` Marc Zyngier
2023-07-04 15:31       ` Marc Zyngier
2023-07-04 15:50 ` [PATCH v2] " Lorenzo Pieralisi
2023-07-04 15:50   ` Lorenzo Pieralisi
2023-07-17 12:57   ` [irqchip: irq/irqchip-fixes] " irqchip-bot for Lorenzo Pieralisi
  -- strict thread matches above, loose matches on Subject: below --
2023-07-07 11:45 [PATCH] " Chunhui Li (李春辉)
2023-07-07 12:14 Chunhui Li (李春辉)
2023-07-09  8:20 ` Marc Zyngier
2023-07-09  8:20   ` Marc Zyngier
2023-07-10  6:00   ` Chunhui Li (李春辉)
2023-07-10  6:00     ` Chunhui Li (李春辉)
2023-07-11  2:03     ` Chunhui Li (李春辉)
2023-07-11  2:03       ` Chunhui Li (李春辉)
2023-07-12  1:40 Chunhui Li (李春辉)
2023-07-12  7:21 ` Marc Zyngier
2023-07-12  7:21   ` Marc Zyngier

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=86sfa3wvj5.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Cheng-Yuh.Wu@mediatek.com \
    --cc=hanks.chen@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@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.