From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by mx.groups.io with SMTP id smtpd.web10.13177.1633964514429262241 for ; Mon, 11 Oct 2021 08:01:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20210112.gappssmtp.com header.s=20210112 header.b=7vAB9HbL; spf=pass (domain: nuviainc.com, ip: 209.85.221.47, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f47.google.com with SMTP id r10so57237178wra.12 for ; Mon, 11 Oct 2021 08:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=LwuPs0nw/daPJsFl9XCCqjsaf+ctegmA9Az2HKDcdbA=; b=7vAB9HbLBI6hIFtLfiqj0qrD/lHrBTYotmshT7OslXX71Hot9Qg2tXihhofNlk9Z5D AMfIbVd0VzmwLh/4kKI8YYB8q82NCOy6fz56AM/FAZUv4OWq2ZeAmVpKXP/npz7veB1K N+n+6ioemvDG9G8i3cOwHsAOVjC/iJDrZ978E1OIizUTZgrfwnS2Xza//hI4hDIrIeIK mEA08Vmrg4AiLftCGy7eKU+pXDHOF0J/W0tAU137i417jGgWd1hdqn3OQ52qqcnUb9M3 o8t2IJzhyOiAFKpLRBmkivpR527IYjLqJxTCYuAMXTtnhIVdj9tnuYfNYY6gCZSEApSj oqUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LwuPs0nw/daPJsFl9XCCqjsaf+ctegmA9Az2HKDcdbA=; b=Q6IAe6mo9NFH6xVke/zbftDj2WlpUr191GkiU5b9mAE8O6q/yGwDgJrigU0m4Y5Sqb 1xxHQ2tdEAtQBbhfGRh54vEloZZtFHaVCD4nAgKH2wGhs+v0MYAZ+k9crv55YJ4lnelM Leybomy8dz9+nxnAl6TLHUNOjdv/tKdVi0I19NAF//Gu7uSJxxMCiGlOCIRvzSSiZ0cX e4tamm623vslhKlXErnyXBGMQvzp6SzBDrcC6zKG9HSrutzzpZf56WuTUIDGSQRzPAAf vnEAX41X4/XFPouW+KzJ4k3SQbvFD7hIjF5IKlnU85WoNEjZxTXwMZkUPzARkoqV20Aq BWqg== X-Gm-Message-State: AOAM531Oqba8UbqsfRqwL+0InarXCygQv0WPmSXMn0VUSHit3bN5R0Yj 9As4ddMyBt+uzR0l1BLUkTtheQ== X-Google-Smtp-Source: ABdhPJwg/CvuWX5MK4zbvjoIEEwfTEUSoQkYe6hDH7trqVDZ+tkEKYt24fwcRNQRgODtGMdjr201dQ== X-Received: by 2002:a05:600c:350c:: with SMTP id h12mr10596192wmq.163.1633964512649; Mon, 11 Oct 2021 08:01:52 -0700 (PDT) Return-Path: Received: from leviathan (cpc92314-cmbg19-2-0-cust559.5-4.cable.virginm.net. [82.11.186.48]) by smtp.gmail.com with ESMTPSA id r27sm8114197wrr.70.2021.10.11.08.01.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Oct 2021 08:01:52 -0700 (PDT) Date: Mon, 11 Oct 2021 16:01:50 +0100 From: "Leif Lindholm" To: rfc@edk2.groups.io, samer.el-haj-mahmoud@arm.com Cc: Ard Biesheuvel , Ard Biesheuvel , Sami Mujawar , edk2-devel-groups-io , Rebecca Cran , Gerd Hoffmann Subject: Re: [edk2-rfc] [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64 Message-ID: <20211011150150.prd5y43ncczp7qkb@leviathan> References: <20210925021752.20678-1-rebecca@nuviainc.com> <20210928111435.poztq4cksagsogbw@leviathan> <20211007094125.soldrzx7wfoa5kyw@leviathan> <20211007110236.5p63sfsxnlrx7tix@leviathan> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Samer, On Mon, Oct 11, 2021 at 14:20:17 +0000, Samer El-Haj-Mahmoud wrote: > > 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. > > The PI 1.7 spec defined the EFI_MP_SERVICES_PROTOCOL in page 2-180, > with the PPI and MM versions in 1-193 and 4-57 respectively. Yes, I was referring to references, as in any protocols explicitly stating compatibility with being called from an AP. > > 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. > > This statement (from the PI spec) is overly ambitious. I bet that it > does not hold true today on most DXE-based UEFI implementations on > other architectures, not just AARCH64. If we agree, I will file an > ECR to remove this statement from the PI spec. That feels like a weird response to the submission of a patch set adding the functionality for AArch64. > > From AARCH64 SBBR systems point of view: > > * The requirements from Arm SBBR point of view are around using > PSCI to online/offline Secondary cores, and leaving them > offlined before ReadyToBoot is signaled. SBBR is not relevant here. PI covers firmware internals, not OS boot compatibility. > * PI-based UEFI implementations are not required. And even when > they are implemented, the EFI_MP_SERVICES_PROTOCOL is not > required So ARM's strategy is to encourage people not to us it *in* PI implementations, even when it is portably implemented on top of PSCI? Regards, Leif > * I agree with the analysis in this thread. EFI_MP > implementations on AARCh64 need to be severely limited in the > general case. Platforms (upstream or downstream) can still > innovate and write their own code to run in these services as > they wish. > > > Thanks, > --Samer > > > > From: Leif Lindholm > Sent: Monday, October 11, 2021 8:28 AM > To: Ard Biesheuvel ; Samer El-Haj-Mahmoud > Cc: Ard Biesheuvel ; Sami Mujawar ; edk2-devel-groups-io ; Rebecca Cran ; Gerd Hoffmann ; edk2 RFC list > Subject: Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64 > > +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 > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > > > >