Mike,
Moving the PageTableLib to MdePkg today also requires all downstream DSC files to be updated to use the instance in MdePkg.
Because MpInitLib today depends on PageTableLib already due to the change to put AP in 64bit before handling to OS.
But you remind me to search for other modules manipulating PageTableLib in MdeModulePkg, or any other packages that should not depend on UefiCpuPkg.
I found:
Because CapsulePei doesn’t need to use PageTableLib in 64bit PEI mode, I am fine with leaving CapsulePei duplicating the page table manipulating code.
+ Ard to see some feedback from ARM side.
Thanks,
Ray
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Wednesday, April 19, 2023 3:07 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Tan, Dun <dun.tan@intel.com>
Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
Hi Ray,
There are other discussions to add more arch specific content to MdeModulePkg
https://edk2.groups.io/g/devel/message/101104
The tradeoff here is moving a lib class from UefiCpuPkg to MdePkg vs defining a new lib class/instance and requiring all downstream DSC files to be updated for the new lib instance.
Moving the lib class is simpler and has less impact and we have done this a few times before (e.g. CpuLib)
I agree we need to be careful about ho much content we move into MdePkg. However, for this specific topic, if we want to maximize the use of the Page Table Library and remove redundant code that manages page tables, moving to MdePkg may
be the best option.
Mike
From: Ni, Ray <ray.ni@intel.com>
Sent: Saturday, April 15, 2023 10:21 PM
To: Kinney, Michael D <michael.d.kinney@intel.com>;
devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Tan, Dun <dun.tan@intel.com>
Cc: Gao, Liming <gaoliming@byosoft.com.cn>
Subject: RE: [edk2-devel] [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
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:
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.
Thanks,
Ray
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Saturday, April 15, 2023 11:57 PM
To: Ni, Ray <ray.ni@intel.com>;
devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Tan, Dun <dun.tan@intel.com>
Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
Back in 2019, I had proposed some more generic rules for package dependencies.
https://edk2.groups.io/g/devel/message/52211
https://github.com/mdkinney/edk2/wiki/EDKII-Packages#edk-ii-package-dependency-rules
The EDK II DEC files do not have enough meta-data to apply these rules. Would require some extra
Define values or well-known tags in comments. The current package dependency checker uses a
set of named packages.
Mike
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Saturday, April 15, 2023 8:50 AM
To: Ni, Ray <ray.ni@intel.com>;
devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Tan, Dun <dun.tan@intel.com>
Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
MdePkg: Include files for industry standard and public specs and lib classes and lib implementations that support those specs
If all the IA32/X64 CPU header files to support the CpuPageTableLib class are in the MdePkg, then we could consider
moving he class to MdePkg and avoid this patch.
The current CpuPageTableLib looks IA32/X64 specific. Should it follow the naming conventions in the EDK II C Coding Style Spec
updated by Abner? It does not look like the current CpuPageTableLib APIs would apply to other CPU archs.
MdePkg does not have any modules. UefiCpuPkg contains CPU specific modules. UefiCpuPkg can also contain libs
that are required by modules in the UefiCpuPkg or modules in other Si/Platform packages.
Thanks,
Mike
From: Ni, Ray <ray.ni@intel.com>
Sent: Friday, April 14, 2023 9:08 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>;
devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Tan, Dun <dun.tan@intel.com>
Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
Mike,
What's the rule regarding content in mdepkg and cpupkg?
thanks,
ray
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Friday, April 14, 2023 11:16:45 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Wang, Jian J <jian.j.wang@intel.com>;
Tan, Dun <dun.tan@intel.com>
Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Ni, Ray <ray.ni@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
If components outside the UefiCpuPkg need access to the CpuPageTableLib, should we
consider moving CpuPageTableLib to MdePkg or MdeModulePkg? There are many different
boot phases that need to crate/manage page tables, so we need to find the right
common location. Perhaps the only part that needs to be moved is the lib class?
Mike
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Wang, Jian J
> Sent: Friday, April 14, 2023 2:03 AM
> To: Tan, Dun <dun.tan@intel.com>;
devel@edk2.groups.io
> Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Ni, Ray <ray.ni@intel.com>
> Subject: Re: [edk2-devel] [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
>
> MdeModulePkg has never depended on UefiCpuPkg before. Please double
> check if there's any side effect introduced by this mutual dependency.
>
> Acked-by: Jian J Wang <jian.j.wang@intel.com>
>
>
> > -----Original Message-----
> > From: Tan, Dun <dun.tan@intel.com>
> > Sent: Friday, March 31, 2023 5:34 PM
> > To: devel@edk2.groups.io
> > Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Ni, Ray <ray.ni@intel.com>;
> > Wang, Jian J <jian.j.wang@intel.com>
> > Subject: [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass
> > DependencyCheck
> >
> > Add UefiCpuPkg/UefiCpuPkg.dec in MdeModulePkg.ci.yaml to pass
> > DependencyCheck since DxeIpl in MdeModulePkg needs to consume
> > CpuPageTableLib in UefiCpuPkg.
> >
> > Signed-off-by: Dun Tan <dun.tan@intel.com>
> > Cc: Liming Gao <gaoliming@byosoft.com.cn>
> > Cc: Ray Ni <ray.ni@intel.com>
> > Cc: Jian J Wang <jian.j.wang@intel.com>
> > ---
> > MdeModulePkg/MdeModulePkg.ci.yaml | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.ci.yaml
> > b/MdeModulePkg/MdeModulePkg.ci.yaml
> > index f69989087b..d2616f4cdc 100644
> > --- a/MdeModulePkg/MdeModulePkg.ci.yaml
> > +++ b/MdeModulePkg/MdeModulePkg.ci.yaml
> > @@ -2,7 +2,7 @@
> > # CI configuration for MdeModulePkg
> > #
> > # Copyright (c) Microsoft Corporation
> > -# Copyright (c) 2020, Intel Corporation. All rights reserved.<BR>
> > +# Copyright (c) 2020 - 2023, Intel Corporation. All rights reserved.<BR>
> > # (C) Copyright 2021 Hewlett Packard Enterprise Development LP<BR>
> > # SPDX-License-Identifier: BSD-2-Clause-Patent
> > ##
> > @@ -51,7 +51,8 @@
> > "MdePkg/MdePkg.dec",
> > "MdeModulePkg/MdeModulePkg.dec",
> > "StandaloneMmPkg/StandaloneMmPkg.dec",
> > - "ArmPkg/ArmPkg.dec" # this should be fixed by promoting an
> > abstraction
> > + "ArmPkg/ArmPkg.dec", # this should be fixed by promoting an
> > abstraction
> > + "UefiCpuPkg/UefiCpuPkg.dec"
> > ],
> > # For host based unit tests
> > "AcceptableDependencies-HOST_APPLICATION":[
> > --
> > 2.31.1.windows.1
>
>
>
>
>