Re: [edk2-devel] [RFC 07/13] MdeModulePkg/DxeCore: Permit preliminary CPU arch fallback

["Ard Biesheuvel" <ardb@kernel.org>]

On Mon, 13 Feb 2023 at 22:32, Marvin Häuser <mhaeuser@posteo.de> wrote:
>
> Without wanting to blow up your RFC with another one - I discussed this with various people, including Bret when he was still at Project Mu, and there was a consensus among them that integrating the whole CPU arch code right into DxeCore would be a good idea. This would especially remove the hack that queues permission applications till CpuDxe loads for good, rather than requiring pro-active consumption of a library that proves this "fallback". For most of the architectural protocols, especially SecurityStubDxe, I never got the gist why you would want them to be separate from DxeCore. Obviously there should be a level of customizability for IBVs and OEMs, though that can be done statically-linked as well.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3223
>
> What's your take on this?
>

My take is that page table manipulation should not be part of the CPU
arch protocol. The DXE core loads images and dispatches them, which
also involves cache maintenance, for instance, as code pages need to
be invalidated from the I-cache before you can execute a newly loaded
image. I think it makes perfect sense for the DXE core to be in charge
of updating the page table descriptors as well.

In my approach, the library version is only used before the CPU arch
protocol appears, so it addresses some of the concerns regarding
multiple owners. But I'd prefer to see this removed from the CPU arch
protocol entirely, or at least for the CPU arch protocol interface to
be deprecated, and redefined in terms of a new DXE services, for
instance, that is implemented by the DXE core itself. That way, all
existing users would still see the same protocols, but the way they
depend on each other would be inverted.