Messages in this thread | | | Date | Tue, 04 Jul 2023 16:23:10 +0100 | From | Marc Zyngier <> | Subject | Re: [PATCH] irqchip/gic-v3: Workaround for GIC-700 erratum 2941627 |
| |
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.
| |