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.
next prev parent 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.