From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 6112D7803D0 for ; Tue, 5 Mar 2024 11:50:45 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=vkHYGYWkEZW+rZNAGKal07H20gIUkBC7oS/KMro0HdY=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1709639444; v=1; b=XX3YxMXEde8Y8f4m9wZRaP//Wlk9hCsnTyNLo7lR+LukKwRLXRPIRTPHL1ntygPWGfTC//x0 cjDKQbAAwfix9Z3nQ29pPIoFjL2Bt3tizwbE0Y1CP5Q7zQoKEk+Np6ljgHswm94oODpyfqk9T/+ GxSQzQjUOs0oVcfCuGCDPdVI= X-Received: by 127.0.0.2 with SMTP id ll3YYY7687511xLkUGX3yaZU; Tue, 05 Mar 2024 03:50:44 -0800 X-Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web10.20633.1709639441705685080 for ; Tue, 05 Mar 2024 03:50:42 -0800 X-Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8Ax++gNB+dlmMEUAA--.32132S3; Tue, 05 Mar 2024 19:50:38 +0800 (CST) X-Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Bx8OQLB+dlM4pOAA--.12500S3; Tue, 05 Mar 2024 19:50:35 +0800 (CST) Message-ID: <2410a5de-b801-4639-a662-49f0b4006990@loongson.cn> Date: Tue, 5 Mar 2024 19:50:35 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] [PATCH v8 14/37] UefiCpuPkg: Add CpuMmuLib to UefiCpuPkg To: Laszlo Ersek , devel@edk2.groups.io, "Ni, Ray" Cc: "Dong, Eric" , "Kumar, Rahul R" , Gerd Hoffmann , Baoqi Zhang , Dongyan Qian , Xianglai Li , Bibo Mao References: <20240126062715.3099433-1-lichao@loongson.cn> <20240126062919.3101691-1-lichao@loongson.cn> <856ebd67-d345-6e41-2e34-74b9bdd7ed7e@redhat.com> <2187d8cd-3578-4f3f-a158-2961571f851b@loongson.cn> <8e97514d-cd2f-881a-f1e4-ed1bdbd03320@redhat.com> <0dd107d1-4e12-45d7-ac27-a755272c55c2@loongson.cn> <5a32d905-fe40-9db0-de3f-3e90919e0bc3@redhat.com> From: "Chao Li" In-Reply-To: <5a32d905-fe40-9db0-de3f-3e90919e0bc3@redhat.com> X-CM-TRANSID: AQAAf8Bx8OQLB+dlM4pOAA--.12500S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQAHCGXm1+YCgQAAs- X-Coremail-Antispam: 1Uk129KBj93XoW7uw18KFW8ZFy8Zw17Wr18tFc_yoW8uFWDpF 95Grn8Crn7Ja4rXrs2yw4rXF1F9rs7Gay5Jwn0kr9rCwn8uFyS9FW8KwnrGFy7ursxtw1Y gw4Ygw4UZFZ8G3gCm3ZEXasCq-sJn29KB7ZKAUJUUUU5529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3UbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRJUUUkCb4IE77IF4wAF F20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r 1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAF wI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67 AKxVWxJr0_GcWl84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x0 82IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMcIj6xIIjxv20xvE14v26r1Y6r17Mc Ij6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41l7480 Y4vEI4kI2Ix0rVAqx4xJMxkF7I0En4kS14v26r126r1DMxAIw28IcxkI7VAKI48JMxC20s 026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_ JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14 v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xva j40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJV W8JbIYCTnIWIevJa73UjIFyTuYvjxUFUUUUUUUU Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lichao@loongson.cn List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 0UHCG6g5dEiwENVi4fFXu4sux7686176AA= Content-Type: multipart/alternative; boundary="------------7bU6SuRpYzHaYYfsbqIencUl" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=XX3YxMXE; dmarc=none; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io --------------7bU6SuRpYzHaYYfsbqIencUl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Laszlo, OK, I see, let's me try. And I have another question: Where should the low-level library be placed? Under the=20 UefiCpuPkg/Library and as the same folder as CpuMmuLib? 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: (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 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116377): https://edk2.groups.io/g/devel/message/116377 Mute This Topic: https://groups.io/mt/103971653/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --------------7bU6SuRpYzHaYYfsbqIencUl Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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?


=
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/11497=
2> (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:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#116377) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--------------7bU6SuRpYzHaYYfsbqIencUl--