From: "Ard Biesheuvel" <ardb@kernel.org>
To: Rebecca Cran <rebecca@nuviainc.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Gerd Hoffmann <kraxel@redhat.com>,
Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>,
Leif Lindholm <leif@nuviainc.com>,
Sami Mujawar <sami.mujawar@arm.com>
Subject: Re: [PATCH v3 1/4] ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO struct
Date: Mon, 31 Jan 2022 00:22:01 +0100 [thread overview]
Message-ID: <CAMj1kXH6KH2AxhzNLLArbsXHGSTe9LF2NAfxM9uT1xhBQVLc2Q@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXHSNc-UHZ=sWFCZ25TxUWzObGJ=NGK4oUeSZeuP9dX0Pw@mail.gmail.com>
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
This still needs the coherency management changes, I'll have a go at
that later this week unless anyone else beats me to it.
next prev parent reply other threads:[~2022-01-30 23:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 3:46 [PATCH v3 0/4] ArmPkg,ArmVirtPkg: Add support EFI_MP_SERVICES_PROTOCOL on AARCH64 Rebecca Cran
2021-12-16 3:46 ` [PATCH v3 1/4] ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO struct Rebecca Cran
2022-01-30 10:44 ` Ard Biesheuvel
2022-01-30 23:22 ` Ard Biesheuvel [this message]
2022-01-31 11:42 ` Ard Biesheuvel
2022-02-04 19:13 ` Rebecca Cran
2021-12-16 3:46 ` [PATCH v3 2/4] ArmPkg: Add Library/MpInitLib to support EFI_MP_SERVICES_PROTOCOL Rebecca Cran
2021-12-16 3:46 ` [PATCH v3 3/4] ArmVirtPkg: Add MpInitLib, which is dependency for CpuDxe consumers Rebecca Cran
2021-12-16 3:46 ` [PATCH v3 4/4] ArmPkg: Update Drivers/CpuDxe to initialize MpInitLib Rebecca Cran
2021-12-17 18:08 ` [PATCH v3 0/4] ArmPkg,ArmVirtPkg: Add support EFI_MP_SERVICES_PROTOCOL on AARCH64 Ard Biesheuvel
2021-12-17 18:40 ` Rebecca Cran
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-list 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=CAMj1kXH6KH2AxhzNLLArbsXHGSTe9LF2NAfxM9uT1xhBQVLc2Q@mail.gmail.com \
--to=devel@edk2.groups.io \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox