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.web08.25302.1643584937849292697 for ; Sun, 30 Jan 2022 15:22:18 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=gkc/Bx1K; 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 9089EB828EF for ; Sun, 30 Jan 2022 23:22:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69D46C340F0 for ; Sun, 30 Jan 2022 23:22:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643584934; bh=6TOHrIBdK8wy+Pm/KP7W2RvT+i6Xs2xZAXUVD77QQPQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gkc/Bx1KuIRLgKGHf0bmp5Y1fx4ZwSOHg/uZ9YTZwSOw+azYLsCtv4kMUmkkY1ER1 urV62y96QEHi3FFgyuY3OLRhw6dsSPiNyhkaa8ZiTVl/Br925VjT03GtpzcTip8S2J a38fviW0s3RfwgDEewZjdO1XsVFwrGfjk1JjXAvwPehfhGjRuamYzYYHLXotpER7Lf qzlvFHc1eBMjfhPZFrTQxdwRTpz/uKHh6zNd/5qCDmbLxyao08pfV6RTWh8s6H+tt9 FvLiKZwlPSTx/7RUaWetD+uITAV3j8ZR4sryOuYCy4NRk5XhpDupjQfTCHilHURYge 0CIvfBastq1tg== Received: by mail-wm1-f51.google.com with SMTP id f202-20020a1c1fd3000000b0034dd403f4fbso8174719wmf.1 for ; Sun, 30 Jan 2022 15:22:14 -0800 (PST) X-Gm-Message-State: AOAM530GLivTkSs24R6VMfbVryirELB485EvKvkM5OUQLxQ4YdZaJeYp ucME2TZDgBCi4el7MZsJUVcZwH0ubjCHefKjdiQ= X-Google-Smtp-Source: ABdhPJw0LZnYxtZlEihLU8MTPx2CU+NWp2O8VoPB9lsd2RuRJAVbKb+losGEfw4NXrkma5zRuBjNzbURTZWfRGxcPtQ= X-Received: by 2002:a05:600c:2b89:: with SMTP id j9mr16194390wmc.190.1643584932693; Sun, 30 Jan 2022 15:22:12 -0800 (PST) MIME-Version: 1.0 References: <20211216034634.15468-1-rebecca@nuviainc.com> <20211216034634.15468-2-rebecca@nuviainc.com> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 31 Jan 2022 00:22:01 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/4] ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO struct 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 Sun, 30 Jan 2022 at 11:44, Ard Biesheuvel wrote: > > Hello Rebecca, > > On Thu, 16 Dec 2021 at 04:46, Rebecca Cran wrote: > > > > Remove the ClusterId and CoreId fields in the ARM_CORE_INFO structure in > > favor of a new Mpidr field. Update code in > > ArmPlatformPkg/PrePeiCore/MainMPCore and ArmPlatformPkg/PrePi/MainMPCore.c > > to use the new field and call new macros GET_MPIDR_AFF0 and GET_MPIDR_AFF1 > > instead. > > > > Signed-off-by: Rebecca Cran > > I am going to merge this patch into EDK2 in isolation, along with the > edk2-platforms changes to keep things working. > > For the remainder of the series, there are two issues that I think > should be resolved. Apologies for not mentioning this before. > > 1) Can we make the MP protocol a separate driver? That would be > cleaner in terms of breakage of other platforms re MpInitLib, and it > would also help with the next point. > > 2) I don't see any management of coherency between the BSP and the APs > (unless I am missing something). I think it would be best to treat APs > as non-coherent masters (given that they boot with the MMU disabled), > which means that every variable in memory that is used to pass > information between BSP and AP needs to be DMA mapped and unmapped > appropriately, and follow the ownership rules of DMA mappings. > > On platforms where none of this is needed, the DmaLib dependency can > be satisfied by CoherentDmaLib, whereas other platforms can use the > non-coherent version instead, which does all the tedious cache > maintenance. > > Given that library dependencies can be specified per-driver in .DSC > file, using a separate driver permits us to pick the right DmaLib > without forcing it upon other parts of the code. It should also > prevent circular dependency issues for DmaLib implementations that > DEPEX on the CPU arch protocol produced by CpuDxe. > I've had a stab at refactoring this code. Branch can be found here: https://github.com/ardbiesheuvel/edk2/tree/armpkg-mpservicesdxe-refactor This still needs the coherency management changes, I'll have a go at that later this week unless anyone else beats me to it.