Re: [edk2-devel] [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck

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

On Sun, 16 Apr 2023 at 07:21, Ni, Ray <ray.ni@intel.com> wrote:
>
> Mike,
>
> MdeModule belongs to the common-package category.
>
> I agree that the common-package should not depend on a specific arch.
>
> MdeModule depending on UefiCpu because DxeIpl needs to prepare an arch specific environment for DXE phase.
>
>
>
> So, I am thinking if the arch-specific-env-preparation can be abstracted through an arch-agnostic API.
>
> Then each arch can implement a concrete instance for that API. The API itself can be in MdeModule pkg.
>
>
>
> In fact, the API is almost already there: “HandOffToDxeCore”.
>
>
>
> So, we could:
>
> Create a new API HandOffToDxeCore() in a new TBD lib class
> Implement different instances for different arch.
> Default instance does nothing arch specific and can be used by EmulatorPkg platform
>
> Today EmulatorPkg uses X64 version of HandOffToDxeCore and skips page table building by setting PcdDxeIplBuildPageTables to FALSE.
>
> UefiCpuPkg implements the HandOffToDxe() for IA32 and X64.
>
>
>
> So, the dependency is reversed: only UefiCpu depends on MdeModule.
>
>
>
> This also removes the arch-specific contents from MdeModulePkg.
>
>
>
> One side effect is: every platform needs to include the new TBD lib class.
>
>
>
> I agree that moving to MdePkg also works. But we might end up with a bigger and bigger MdePkg by including more and more.
>
>
>

I would prefer this approach. CpuPageTableLib is very x86-specific and
does not comply with the requirements for MdePkg.

Loading DXE core and mapping it with restricted permissions (to avoid
W+X memory) will require some kind of abstraction here in any case, so
it would be better to let the x86 specific version of that live in
UefiCpuPkg, and keep this out of MdePkg entirely.