From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web10.7.1639764547134583660 for ; Fri, 17 Dec 2021 10:09:07 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=u32ApZRc; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BCFBAB82A08 for ; Fri, 17 Dec 2021 18:09:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81B09C36AE1 for ; Fri, 17 Dec 2021 18:09:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639764543; bh=Yx4i0VwjW4amT6vRglFRuzkK+MGbh33WmqklhoOPlwI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=u32ApZRcWY0nrojgKFXaR9FFghDHpmId2mfu7TmN0uk/+HCjIu0WWhV8VsH1B+nsv y6maNV2XSOEds2Oxe63JxpY7WIMDqDJbCcfcFwgBIhBBYlRXipnd1bqEHrp1LG8N+o /7c0bL843fgBb6vFt+HWiY5ys8AGEml2hCfC37xOha36cDWXIkLWUJbXOfGrkhR3aH XNNzed4/fZ6YtI67YwPxiFfSbe8Wby5hbX30io4uIdDAqlAG7lEvP0CiB2I1qvCcTC M580lbwwauMiGYusXaQkROzRpgHBznsW/GBDQG12UIpXDj3CaHZuwq0JeErsqVrDOA PiwawTIbOqy3A== Received: by mail-wr1-f42.google.com with SMTP id j9so5708052wrc.0 for ; Fri, 17 Dec 2021 10:09:03 -0800 (PST) X-Gm-Message-State: AOAM5316nezPo0LZxzMrADYpx7v3YLy8DCm1HHYJBPdEEJNtd+36ydgk ic8ElsZpehn89fiToU0U3RyLJ57InxQvd7QcwAE= X-Google-Smtp-Source: ABdhPJwHtgtvpednVdYE03sFrLa+PQAz+JiPebKBrqJHJWogvcdl+yis4XplrasRuu9SJ4b1/NiepU6q6YiWufakns4= X-Received: by 2002:adf:dc44:: with SMTP id m4mr3528464wrj.550.1639764541813; Fri, 17 Dec 2021 10:09:01 -0800 (PST) MIME-Version: 1.0 References: <20211216034634.15468-1-rebecca@nuviainc.com> In-Reply-To: <20211216034634.15468-1-rebecca@nuviainc.com> From: "Ard Biesheuvel" Date: Fri, 17 Dec 2021 19:08:50 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 0/4] ArmPkg,ArmVirtPkg: Add support EFI_MP_SERVICES_PROTOCOL on AARCH64 To: Rebecca Cran Cc: edk2-devel-groups-io , Ard Biesheuvel , Gerd Hoffmann , Samer El-Haj-Mahmoud , Leif Lindholm , Sami Mujawar Content-Type: text/plain; charset="UTF-8" On Thu, 16 Dec 2021 at 04:46, Rebecca Cran wrote: > > Patch 1/4 is the start of addressing the issue that the Aff0 field of > the MPIDR is no longer guaranteed to be the core, and should be referred > to in a more generic way: for example it could be the thread, with Aff1 > being the core and Aff2 the cluster. Clearly much more work is needed > to fully remove that assumption. > > Patch 2/4 implements the EFI_MP_SERVICES_PROTOCOL for DXE in Library/MpInitLib. > Patch 4/4 updates CpuDxe to initialize MP support: as a result, it gains > a dependency on MpInitLib. > Patch 3/4 updates ArmVirt.dsc.inc to add the new MpInitLib library. > > Cores are powered on and turned off using PSCI. > > Note that minimal CPU setup is done: for example the MMU and caches are > left disabled. > > -------- > > Changes from v2: > > o Split patches up. > o Wrapped overly long lines. > o Fixed code formatting issues (Uncrustify). > o Fixed other formatting issues (ECC tool). > > -------- > > Testing: > > o Ran CI: https://github.com/tianocore/edk2/pull/2312 > o Built packages in ArmVirtPkg at each revision for both ARM and AARCH64. > > Rebecca Cran (4): > ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO > struct > ArmPkg: Add Library/MpInitLib to support EFI_MP_SERVICES_PROTOCOL > ArmVirtPkg: Add MpInitLib, which is dependency for CpuDxe consumers > ArmPkg: Update Drivers/CpuDxe to initialize MpInitLib > OK, this looks good to me in principe, and I am quite happy with the implementation of the MpInitLib and the new ability to dispatch execution to other cores. However, looking at ArmPkg/Include/Guid/ArmMpCoreInfo.h, I was seriously shocked at how much cruft has accumulated there: - headers under Guid/ shouldn't carry that many vaguely related definitions anyway - the mailbox stuff is obsolete - the pseudo-ACPI table (ACPI style header but published as a EFI config table) is highly dubious as well, and should really just be removed. I don't want to derail this series further, so I''ll have a stab at cleaning this up on top, unless there are any reasons for keeping this stuff?