From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by mx.groups.io with SMTP id smtpd.web09.10942.1633955292490423031 for ; Mon, 11 Oct 2021 05:28:12 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20210112.gappssmtp.com header.s=20210112 header.b=aTujuPEI; spf=pass (domain: nuviainc.com, ip: 209.85.219.175, mailfrom: leif@nuviainc.com) Received: by mail-yb1-f175.google.com with SMTP id z5so38663484ybj.2 for ; Mon, 11 Oct 2021 05:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uDjWHeKtbUmN9SBitjQZ6G3Q7nosIJugBXsGELnqKhs=; b=aTujuPEIBFaR236aLKwIWkOmjODT/pcbtGg/I6gQmrFwvDYAheyZGZf8NDdtM7d9lH tsntcLoLHNSMnbuxpZa49+fHhqSpfHo4gKT9AO0IealSKu1lpuvhSk9NdX1NhqMXlR27 lJtbiKQKhzU7KWp7QWnmHsBhN4a0u9sTOixcWrDnRW9VBMnhppdbiUELxlvYO17s76Uh ZAW6ANHsTHmnpPNyhzSw+UkNbomFvSyI9Rx2Tjz9xute38w3z0Ax5X6FRPQJjk2ihB2f 08dWNDWjSE3SBUuQbd7jub834qclPblOzXaFYOQzoV2Ppi1GZg2h1EOZEj6yOaFXJgWA mV6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uDjWHeKtbUmN9SBitjQZ6G3Q7nosIJugBXsGELnqKhs=; b=tL12Lr3spbzrA9j0i0AP3Ps9KptV/1AGEPS42bTG8WIV1kS5Ui9ifcMhsazp+E89VC 8Cc7Oo0RQFKFUrEzFI73cdYiOr6dDfMqYj4y53VIOIpTY47FVLGeiF00Y+oDkp+F9p1j KPvu13xE6k2FZRatCjcRuBUAptvPLqur+1IZBH0ML762ZOr3kqcJ8s8MiaaitlIngTwR uJ9QX1HuxlblmAuDxTrOr8tY4x5qRrpjZT+w8tsx29SzjNpm4MifHZmkpX9nsrfSdf85 2GnDFb/CMXG86dlwjo7XQFqqHndNn7rD7ICAT4dJNKjZqyLRlQ6e0cQ0jtUxrlomtgV6 HX5A== X-Gm-Message-State: AOAM531qITxjB1gFJEcddbtEviFMIeAvgMhNnKbnEMzYP7ikM2mbH0x7 Ml/nMcsnbDqlrjbktJlkoOYExnnIqNvili4t2yeRPg== X-Google-Smtp-Source: ABdhPJzsQebiwD2DZRpR+i61DgXF9r3BgKBd59ykJ/eMsLyoQHwXTjtfPyI/rDNsF32ASN/71B1XT4XTqVBKnaXH4Uc= X-Received: by 2002:a25:47c6:: with SMTP id u189mr23685809yba.232.1633955291736; Mon, 11 Oct 2021 05:28:11 -0700 (PDT) MIME-Version: 1.0 References: <20210925021752.20678-1-rebecca@nuviainc.com> <20210928111435.poztq4cksagsogbw@leviathan> <20211007094125.soldrzx7wfoa5kyw@leviathan> <20211007110236.5p63sfsxnlrx7tix@leviathan> In-Reply-To: From: "Leif Lindholm" Date: Mon, 11 Oct 2021 13:28:00 +0100 Message-ID: Subject: Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64 To: Ard Biesheuvel , Samer El-Haj-Mahmoud Cc: Ard Biesheuvel , Sami Mujawar , edk2-devel-groups-io , Rebecca Cran , Gerd Hoffmann , edk2 RFC list Content-Type: multipart/alternative; boundary="000000000000be3f2b05ce12dca7" --000000000000be3f2b05ce12dca7 Content-Type: text/plain; charset="UTF-8" +Samer On Fri, Oct 8, 2021 at 3:51 PM Ard Biesheuvel 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 --000000000000be3f2b05ce12dca7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+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 i= t
> > 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<= br> > 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<= br> > 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<= br> 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.
<= div>
But it might be good to hear something from ARM whether = the use of this
protocol which "must be produced on any syst= em with more than one logical processor"
*should* be able to= rely on anything being set up for it, or whether we
need an afor= ementioned helper library.

/
=C2=A0 =C2= =A0 Leif

--000000000000be3f2b05ce12dca7--