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 6CB98780091 for ; Tue, 14 Nov 2023 02:09:06 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=UA/7sLmzKY9dBTQGMUralScT3R+4/3tYiSuTDZDVRzY=; 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=1699927745; v=1; b=fMrvFdy/2yiMxwnxS0xXojtRRlEQOb3qmhkkpL7dVIYEAr43nCQ2u3tyHZD1digEPv1wp7L0 M/2VomS1ixdF6n7Jhq13ml9s7AkDnmQqSFfpyoyZHMyHJJgIvYNpuDHuj9PG04aaZRQ5oh04loa Pkf17phsI+KEu0qZp+4a3/Uw= X-Received: by 127.0.0.2 with SMTP id cnmgYY7687511xTLSYV6bJPi; Mon, 13 Nov 2023 18:09:05 -0800 X-Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web11.4438.1699927743908413779 for ; Mon, 13 Nov 2023 18:09:04 -0800 X-Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8AxDOu91lJlJ805AA--.43368S3; Tue, 14 Nov 2023 10:09:01 +0800 (CST) X-Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Dxzdyc1lJlhWxBAA--.12129S3; Tue, 14 Nov 2023 10:08:28 +0800 (CST) Message-ID: <3b099256-d844-490b-804d-e102d2a0c16b@loongson.cn> Date: Tue, 14 Nov 2023 10:08:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] [PATCH v2 23/30] OvmfPkg/LoongArchVirt: Add PeiServiceTablePointerLib To: devel@edk2.groups.io, lersek@redhat.com Cc: Ard Biesheuvel , Jiewen Yao , Jordan Justen , Gerd Hoffmann , Xianglai Li , Bibo Mao References: <20231106032521.2251143-1-lichao@loongson.cn> <20231106033012.2294174-1-lichao@loongson.cn> <1736e6c6-f455-48f3-9b68-04f2fd2c70ec@loongson.cn> <0568d2a8-54e7-730e-24c2-0c619b886b50@redhat.com> From: "Chao Li" In-Reply-To: <0568d2a8-54e7-730e-24c2-0c619b886b50@redhat.com> X-CM-TRANSID: AQAAf8Dxzdyc1lJlhWxBAA--.12129S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQAPCGVRh6kiYwAEsZ X-Coremail-Antispam: 1Uk129KBj93XoWxXrWDXFyktr1rAr1fGFW7GFX_yoW5tryxpr 4YgrWFkr1kt34kuFyqqw4xXrW0vrs7ZFyayrnYy348Can5JF1ktF10krWF9ayUurs5Zw12 qrWFvw1Dua4DuagCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3UbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRJUUUyCb4IE77IF4wAF F20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r 1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAF wI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67 AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1le2I262IYc4CY6c8I j28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAv7VC0I7IYx2IY67AKxVWUAVWUtw Av7VC2z280aVAFwI0_Gr0_Cr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMx8G jcxK6IxK0xIIj40E5I8CrwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8Jw C20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAF wI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI42IY6xIIjx v20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2 jsIE14v26r4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0x ZFpf9x07UM5l8UUUUU= 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: YI1nSZ6nSoyYV9FTvkyh3iEFx7686176AA= Content-Type: multipart/alternative; boundary="------------14iCnPLB58ZTI5IIEJW5ljLj" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b="fMrvFdy/"; 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 --------------14iCnPLB58ZTI5IIEJW5ljLj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Laszlo, I see, I will look into this PI SPEC and try to implement it in MdePkg=20 first and then to update the SPEC. Thanks, Chao On 2023/11/13 19:02, Laszlo Ersek wrote: > On 11/10/23 07:44, Chao Li wrote: >> Hi Laszlo, >> >> This is a good question, same as the previous email, some ARCH don't >> require running code on memory during PEI phase or other reason can not >> used the MdePkg version, so this pointer will be saved by some register, >> I saw the ArmPkg version also uses a register to save this pointer. >> >> If I move ArmPkg version PeiServiceTablePointer to MdePkg and the method >> of getting and saving the pointer use a new library which related >> architecture, other word, the API of PeiServiceTablePointer has not >> changed, adding a new library that PeiServiceTablePointer depends on, >> the real saving and reading method completed in the new library. Do you >> think this way is better? > Right. I think you need a loongarch-specific library instance of > PeiServicesTablePointerLib under MdePkg. Presumably, if / when you > enable edk2 on *physical* loongarch platforms, you're going to need the > same library instance. And therefore it should not be under OvmfPkg, but > MdePkg. > > In fact, now that I'm reading the comments in > "MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointer.c", > it seems that the architecture bindings in the Platform Init > specification actually document how the PEI services table pointer is > supposed to be stored before system memory becomes available (IIUC). > > The latest version of the PI spec that I have is 1.8. > > In Volume I, there is a section titled "I-9.4 PEI Services Table > Retrieval". It considers the following architectures: X86, x64, Itanium, > ARM, AArch64, RISC-V. > > I think that in the longer term, you should file a PIWG Mantis ticket > for extending this section, with an Engineering Change Request where you > describe how this mechanism should work on loongarch. > > And then the implementation certainly belongs to MdePkg. > > (Note that I'm *not* saying you should first update the specification > and then implement it in edk2 -- that's not my point. My point is that > *eventually*, this mechanism will become a part of the public loongarch > bindings, and therefore you can already start introducing it under > MdePkg, in my opinion anyway.) > > Note that "prior art" is inconsistent here, regarding edk2 locations, > because, as you say, the arm/aarch64 implementation lives under ArmPkg > -- but it's quite unlikely IMO that a LoongArchPkg top-level directory > would be introduced. In the longer term, we might want to consolidate > all PeiServicesTablePointerLib instances under MdePkg. > > > Then your question is, IIUC, whether to reuse any portion of the ArmPkg > implementation. I don't think that's necessary; the library is so small, > there is effectively *nothing generic* in it. Put differently, all of it > is architecture specific. Thus I think you can just add a totally > self-contained loongarch instance. > > Laszlo > > > >=20 > -=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 (#111189): https://edk2.groups.io/g/devel/message/111189 Mute This Topic: https://groups.io/mt/102413901/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- --------------14iCnPLB58ZTI5IIEJW5ljLj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Laszlo,

I see, I will look into this PI SPEC and try to implement it in MdePkg first and then to update the SPEC.


=
Thanks,
Chao
On 2023/11/13 19:02, Laszlo Ersek wrote:
On 11/10/23 07:44, Chao Li wro=
te:

Hi Laszlo,

This is a good question, same as the previous email, some ARCH don't
require running code on memory during PEI phase or other reason can not
used the MdePkg version, so this pointer will be saved by some register,
I saw the ArmPkg version also uses a register to save this pointer.

If I move ArmPkg version PeiServiceTablePointer to MdePkg and the method
of getting and saving the pointer use a new library which related
architecture, other word, the API of PeiServiceTablePointer has not
changed, adding a new library that PeiServiceTablePointer depends on,
the real saving and reading method completed in the new library. Do you
think this way is better?

Right. I think you need a loongarch-specific library instance of
PeiServicesTablePointerLib under MdePkg. Presumably, if / when you
enable edk2 on *physical* loongarch platforms, you're going to need the
same library instance. And therefore it should not be under OvmfPkg, but
MdePkg.

In fact, now that I'm reading the comments in
"MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointer.c",
it seems that the architecture bindings in the Platform Init
specification actually document how the PEI services table pointer is
supposed to be stored before system memory becomes available (IIUC).

The latest version of the PI spec that I have is 1.8.

In Volume I, there is a section titled "I-9.4 PEI Services Table
Retrieval". It considers the following architectures: X86, x64, Itanium,
ARM, AArch64, RISC-V.

I think that in the longer term, you should file a PIWG Mantis ticket
for extending this section, with an Engineering Change Request where you
describe how this mechanism should work on loongarch.

And then the implementation certainly belongs to MdePkg.

(Note that I'm *not* saying you should first update the specification
and then implement it in edk2 -- that's not my point. My point is that
*eventually*, this mechanism will become a part of the public loongarch
bindings, and therefore you can already start introducing it under
MdePkg, in my opinion anyway.)

Note that "prior art" is inconsistent here, regarding edk2 locations,
because, as you say, the arm/aarch64 implementation lives under ArmPkg
-- but it's quite unlikely IMO that a LoongArchPkg top-level directory
would be introduced. In the longer term, we might want to consolidate
all PeiServicesTablePointerLib instances under MdePkg.


Then your question is, IIUC, whether to reuse any portion of the ArmPkg
implementation. I don't think that's necessary; the library is so small,
there is effectively *nothing generic* in it. Put differently, all of it
is architecture specific. Thus I think you can just add a totally
self-contained loongarch instance.

Laszlo
_._,_._,_
Groups.io Links:

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

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

_._,_._,_
--------------14iCnPLB58ZTI5IIEJW5ljLj--