From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web10.10390.1633704705968009754 for ; Fri, 08 Oct 2021 07:51:46 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pu5k39Sn; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 49B2260F9E; Fri, 8 Oct 2021 14:51:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633704705; bh=2xzduktFto2Ttp75jy6sclFDp9E6vAsoSrKsA9BQkhI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=pu5k39SnVtj6dIykBb1hh13hVU6fe2qdxnwNJaO6jvbaBbvwlmYc4hhmgdERSBT7y R5sEGKCwvMMB/AxSGKBQ0l/onPtTURE9VkHCufX8MH+1cMfQ/dX14jMk4zeg76Es3g 1YFVU0QnyhajnXbxTmH/H8FygmbUz3JS3i0p79gMtOplIcgEAHo+rb2HaCDxZ+GFEi NUmbBLTythl+NmVz12IUNGykuK6yHkWE7NBvpA1R6eGFngSpr+bgUvQlV8L73kI6ZN NYKTTYs6lf2GxPEsScimXvMFyCfiNuVJ2yfM04PQoGsuNzOQrhcbGTzKP49tnADUj4 Tr4cVHwmaAC0w== Received: by mail-ot1-f52.google.com with SMTP id l7-20020a0568302b0700b0054e40740571so6275416otv.0; Fri, 08 Oct 2021 07:51:45 -0700 (PDT) X-Gm-Message-State: AOAM532fY453CI9qJ7OCuHILgo81DoYSCiTEdyJSy2ym2sCYIJ1PH3LE GV5rZE4pURzFfsWhO4tIMzx6o+jR2lO5NRaXtqI= X-Google-Smtp-Source: ABdhPJx5mzNch3SgM7qyuHTW0wRhO3aTENcPJAOhEMiJpZ5JlFbeTfvwZdYUoFyscnO82loPlzCfJFZRHFX+4XdSrg0= X-Received: by 2002:a9d:63c7:: with SMTP id e7mr9145751otl.30.1633704704653; Fri, 08 Oct 2021 07:51:44 -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: <20211007110236.5p63sfsxnlrx7tix@leviathan> From: "Ard Biesheuvel" Date: Fri, 8 Oct 2021 16:51:33 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64 To: Leif Lindholm Cc: Ard Biesheuvel , Sami Mujawar , edk2-devel-groups-io , Rebecca Cran , Gerd Hoffmann , edk2 RFC list Content-Type: text/plain; charset="UTF-8" On Thu, 7 Oct 2021 at 13:02, Leif Lindholm wrote: > > On Thu, Oct 07, 2021 at 12:03:30 +0200, Ard Biesheuvel wrote: > > On Thu, 7 Oct 2021 at 11:41, Leif Lindholm wrote: > > > > > > Ard/Sami - any comments? > > > > > > > The code changes by itself look fine to me. The only problem I see is > > that we cannot run arbitrary code on other cores with the MMU off, > > given that in that case, > > This is a good point, and something we at the very least should point > out more explicitly - and perhaps ought to provide a helper library to > do - ... > > > they don't comply with the UEFI AArch64 > > platform requirements, most notably the one that says that unaligned > > accesses must be permitted. > > ... but I'll note that EFI_MP_SERVICES_PROTOCOL is one of those > incorrectly named protocols defined in PI, not UEFI. > > > 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.