OK, I'll give it a try.

Thanks,
Chao

On 2024/3/5 20:09, Laszlo Ersek wrote:

On 3/5/24 12:50, Chao Li wrote:

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?

In my opinion:

Under UefiCpuPkg/Library -- yes.

In the same folder as CpuMmuLib -- no. Instances of different library
classes are never placed in the same folder.

Laszlo


Thanks,
Chao
On 2024/3/5 17:26, Laszlo Ersek wrote:

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.h

I 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

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

_._,_._,_