Hi Laszlo,
OK, I see, let's me try. And I have another question:
Where should the low-level library be placed?
Under the UefiCpuPkg/Library and as the same folder as
CpuMmuLib?
Hello Chao, On 3/4/24 04:39, Chao Li wrote:Hi Laszlo, OK. When I discussed the CpuMmuLib API as a public API with Ray in the early days, the API recommended by Ray should be the patch 13 in this series, which only contains set/get memory region attribute, but in the first version in this series, it contains more API, one is ConfigureMmu API, which is included in ARM and RISCV versions. This API provides a interface called in PEI or DXE stage, it will configures the MMU and enables it, such as creating the page tables, filling the static page tables, cofniguring the MMU registers, enbale MMU, etc. The paths for ARM and RISCV version APIs: ARM: ArmPkg/Include/Library/ArmMmuLib.h RISCV: UefiCpuPkg/Include/Library/BaseRiscVMmuLib.hI have now re-read this subthread in its entirey, and I think I understand what's up. What confused me recently was your expression "so should we open configure API?" I think what you meant by "opening" was "publicly declaring". Anyway, here's my recommendation (consistently with what I said earlier in this thread): - I think you need a new (lower-level) library class and instance for exposing ConfigureMemoryManagementUnit(). Please see: <https://edk2.groups.io/g/devel/message/114972> (msgid <2a91f2f0-df4c-e106-65cd-79be167224f2@redhat.com>). - I do not recommend trying to unify the new LoongArch library classes (low level and high level) with "ArmMmuLib.h" or "BaseRiscVMmuLib.h". Each of "ArmMmuLib.h" and "BaseRiscVMmuLib.h" seems to declare both low-level and high-level interfaces. For LoongArch, we apparently don't want that; hence the idea to introduce two library classes for LoongArch -- that may be considered an improved design. At the same time, I don't believe that this requires us to unify "ArmMmuLib.h" and "BaseRiscVMmuLib.h" with the new, LoongArch-motivated library class design. Laszlo