[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a6gvwioc.wl-maz@kernel.org>
Date: Mon, 20 Dec 2021 12:43:31 +0000
From: Marc Zyngier <maz@...nel.org>
To: Hector Martin <marcan@...can.st>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Rob Herring <robh+dt@...nel.org>,
Sven Peter <sven@...npeter.dev>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH 2/6] irqchip/apple-aic: Add Fast IPI support
On Sat, 18 Dec 2021 05:31:28 +0000,
Hector Martin <marcan@...can.st> wrote:
>
> >> + u64 idx = FIELD_GET(MPIDR_CPU, mpidr);
> >> +
> >> + if (FIELD_GET(MPIDR_CLUSTER, my_mpidr) == cluster)
> >> + write_sysreg_s(FIELD_PREP(IPI_RR_CPU, idx),
> >> + SYS_IMP_APL_IPI_RR_LOCAL_EL1);
> >> + else
> >> + write_sysreg_s(FIELD_PREP(IPI_RR_CPU, idx) | FIELD_PREP(IPI_RR_CLUSTER, cluster),
> >> + SYS_IMP_APL_IPI_RR_GLOBAL_EL1);
> >
> > Don't you need an ISB, either here or in the two callers? At the
> > moment, I don't see what will force the execution of these writes, and
> > they could be arbitrarily delayed.
>
> Is there any requirement for timeliness sending IPIs? They're going to
> another CPU after all, they could be arbitrarily delayed because it has
> FIQs masked.
They absolutely could, but this has a potential impact on the
scheduling if you delay it (the vast majority of these IPIs are to
indicate to the remote CPU that it needs to go and schedule something
else). So there is an incentive for making it happen ASAP.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists