From: "Leif Lindholm" <leif@nuviainc.com>
To: Ard Biesheuvel <ardb@kernel.org>,
Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>,
Sami Mujawar <sami.mujawar@arm.com>,
edk2-devel-groups-io <devel@edk2.groups.io>,
Rebecca Cran <rebecca@nuviainc.com>,
Gerd Hoffmann <kraxel@redhat.com>,
edk2 RFC list <rfc@edk2.groups.io>
Subject: Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64
Date: Mon, 11 Oct 2021 13:28:00 +0100 [thread overview]
Message-ID: <CALDovBuyFYs1FuDXmzqiBhrJV_T=SvoCYsjrzkF9OoMqM5Cwkg@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXFi8CZy=8B5R-Ct1Uw=XOfmqde3dM4yQFLFXjs5pfSH-g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]
+Samer
On Fri, Oct 8, 2021 at 3:51 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > So either we severely constrain the kind of code that we permit to run
> > > on other cores, or we enable the MMU and caches on each core as it
> > > comes out of reset, as well as do any other CPU specific
> > > initialization that we do for the primary core as well.
> >
> > The description for StartupAllAPs() has a note:
> > It is the responsibility of the consumer of the
> > EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() to make sure that the nature
> > of the code that is executed on the BSP and the dispatched APs is well
> > controlled. The MP Services Protocol does not guarantee that the
> > Procedure function is MP-safe. Hence, the tasks that can be run in
> > parallel are limited to certain independent tasks and well-controlled
> > exclusive code. EFI services and protocols may not be called by APs
> > unless otherwise specified.
> >
> > So I think this is actually fine, implementation-wise. *Except* for
> > the SwitchBSP function (where we're currently bailing out anyway).
>
> Ok, so that doesn't look as bad as I thought. But we'll have to be
> more strict than other arches: even EFI services and protocols that
> are marked as safe for execution under this MP protocol are likely to
> explode if they rely on CopyMem() or SetMem() for in/outputs that are
> not a multiple of 8 bytes in case the platform uses the
> BaseMemoryLibOptDxe flavour of this library, since it relies heavily
> on deliberately misaligned loads and stores.
>
I think there is no way a protocol defined in the UEFI specification could
be
safe to use by non-BSP. In PI, the only references I find to the protocol
are
in MM and SAL protocols.
And we're not even looking at EFI_MP_SERVICES_PPI at this point.
But it might be good to hear something from ARM whether the use of this
protocol which "must be produced on any system with more than one logical
processor"
*should* be able to rely on anything being set up for it, or whether we
need an aforementioned helper library.
/
Leif
[-- Attachment #2: Type: text/html, Size: 2731 bytes --]
next prev parent reply other threads:[~2021-10-11 12:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-25 2:17 [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64 Rebecca Cran
2021-09-25 2:17 ` [RFC] [PATCH 1/2] ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO struct Rebecca Cran
2021-09-25 2:17 ` [RFC] [PATCH 2/2] ArmPkg: Add Library/MpInitLib to support EFI_MP_SERVICES_PROTOCOL Rebecca Cran
2021-09-28 11:14 ` [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64 Leif Lindholm
2021-10-07 9:41 ` Leif Lindholm
2021-10-07 10:03 ` Ard Biesheuvel
2021-10-07 11:02 ` Leif Lindholm
2021-10-08 14:51 ` Ard Biesheuvel
2021-10-11 12:28 ` Leif Lindholm [this message]
2021-10-11 14:20 ` Samer El-Haj-Mahmoud
2021-10-11 15:01 ` [edk2-rfc] " Leif Lindholm
2021-10-11 21:52 ` Samer El-Haj-Mahmoud
2021-10-14 13:14 ` Leif Lindholm
2021-10-18 9:21 ` Sami Mujawar
2021-10-18 11:54 ` Leif Lindholm
2022-01-19 10:28 ` [edk2-devel] " Sami Mujawar
2021-10-14 12:41 ` 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='CALDovBuyFYs1FuDXmzqiBhrJV_T=SvoCYsjrzkF9OoMqM5Cwkg@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