Re: [PATCH v3 1/4] ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO struct

["Ard Biesheuvel" <ardb@kernel.org>]

On Mon, 31 Jan 2022 at 00:22, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Sun, 30 Jan 2022 at 11:44, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > Hello Rebecca,
> >
> > On Thu, 16 Dec 2021 at 04:46, Rebecca Cran <rebecca@nuviainc.com> wrote:
> > >
> > > Remove the ClusterId and CoreId fields in the ARM_CORE_INFO structure in
> > > favor of a new Mpidr field. Update code in
> > > ArmPlatformPkg/PrePeiCore/MainMPCore and ArmPlatformPkg/PrePi/MainMPCore.c
> > > to use the new field and call new macros GET_MPIDR_AFF0 and GET_MPIDR_AFF1
> > > instead.
> > >
> > > Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
> >
> > I am going to merge this patch into EDK2 in isolation, along with the
> > edk2-platforms changes to keep things working.
> >
> > For the remainder of the series, there are two issues that I think
> > should be resolved. Apologies for not mentioning this before.
> >
> > 1) Can we make the MP protocol a separate driver? That would be
> > cleaner in terms of breakage of other platforms re MpInitLib, and it
> > would also help with the next point.
> >
> > 2) I don't see any management of coherency between the BSP and the APs
> > (unless I am missing something). I think it would be best to treat APs
> > as non-coherent masters (given that they boot with the MMU disabled),
> > which means that every variable in memory that is used to pass
> > information between BSP and AP needs to be DMA mapped and unmapped
> > appropriately, and follow the ownership rules of DMA mappings.
> >
> > On platforms where none of this is needed, the DmaLib dependency can
> > be satisfied by CoherentDmaLib, whereas other platforms can use the
> > non-coherent version instead, which does all the tedious cache
> > maintenance.
> >
> > Given that library dependencies can be specified per-driver in .DSC
> > file, using a separate driver permits us to pick the right DmaLib
> > without forcing it upon other parts of the code. It should also
> > prevent circular dependency issues for DmaLib implementations that
> > DEPEX on the CPU arch protocol produced by CpuDxe.
> >
>
> I've had a stab at refactoring this code. Branch can be found here:
> https://github.com/ardbiesheuvel/edk2/tree/armpkg-mpservicesdxe-refactor
>

OK, I've did some more work on this, and ended up with a branch that
builds and runs correctly on Raspberry Pi 4. Note that it requires
cache maintenance in the test app as well, or the ApFunction() routine
may be sitting in the cache on the BSP, and the AP will branch to who
knows where.