From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.31252.1643629364831938447 for ; Mon, 31 Jan 2022 03:42:45 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=u9Ut9D9H; spf=pass (domain: kernel.org, ip: 139.178.84.217, 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 dfw.source.kernel.org (Postfix) with ESMTPS id 0D4FF613CA for ; Mon, 31 Jan 2022 11:42:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71AA7C36AE2 for ; Mon, 31 Jan 2022 11:42:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643629363; bh=qU/BjREWsihcrbVyfforihp0jVg+X0YkKwnyG/Sj+90=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=u9Ut9D9HAi/be94mxSUBq0qCtudF0FsqTLnX/OJwpuyV6UiMUZ/qkshnHPhsUC2de Ahgr4y5pmgy1GCq66rFtAY2+i7fv6DZszcU9+XiFmnHMNv88TePcarSn1jHz8YzYV/ PEk8i4lXST4yzRZJdG+DWg/YgUmGHwu1HmjFYWv+kLejhmJoc4D2FNFWF8FnrOh9rV K7dtCbxgDJaKjiNS8eiS9PMks7RhFxt0mWDmXYrGvgv+k3kk7oMZfe7HyufEkLNWJw +qq9KxCFX3/Xnmgc43Lbu1RHptGfbWlOSwNLYuTCr7bwLqX7BTRkB/YHMNnUP+fImb Qp/rKqGePzJ0Q== Received: by mail-wm1-f46.google.com with SMTP id i187-20020a1c3bc4000000b0034d2ed1be2aso13461741wma.1 for ; Mon, 31 Jan 2022 03:42:43 -0800 (PST) X-Gm-Message-State: AOAM532NMjWDBsk3P9/9VWF6TP7dZyVMI7NmRObdgyfGmY1W2sEsmANY n+qAyY3pptzJhbywB0gXD7LFvTQBSaDAduah3aY= X-Google-Smtp-Source: ABdhPJxJ7KQZqFOIWOOGaf6zPm4FvQoshRxCbpZ549xilfLekL2QxCSlxxsXdxXATYC+AV9QxQk+AE6+bRGZ6WI/Dl8= X-Received: by 2002:a05:600c:a47:: with SMTP id c7mr18053989wmq.25.1643629361806; Mon, 31 Jan 2022 03:42:41 -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 12:42:30 +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 Mon, 31 Jan 2022 at 00:22, Ard Biesheuvel wrote: > > 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 > OK, I've did some more work on this, and ended up with a branch that builds and runs correctly on Raspberry Pi 4. Note that it requires cache maintenance in the test app as well, or the ApFunction() routine may be sitting in the cache on the BSP, and the AP will branch to who knows where.