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

["Marvin Häuser" <mhaeuser@posteo.de>]

Sounds good to me, thanks!

Best regards,
Marvin

> On 13. Feb 2023, at 23:07, Ard Biesheuvel <ardb@kernel.org> wrote:
> 
> 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.