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 DE67AAC08EC for ; Fri, 29 Mar 2024 01:29:01 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=zlFGQgY7vL8yi6GJa3D/iMjWy56eTFiy7c8bGbaLPGU=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:Subject:From:To:Cc:Reply-To:References:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20240206; t=1711675740; v=1; b=JvqKOLLQ667rvJOwEbU3q3GNwFBHraLY8gaUh1VlXso2RJJmJAEpGaAJu3FXh3MCP2OWlhoJ N2zBrpxhx47ndosyu4E5Kb0EP+369FMX36W/yKpfD2hxAiKhnYNOTqh+o/+KFwbRtRjksxon3EN X85VHrA18NyBev8grscyPt3vMK61k3rqs/0N1mFODXn4KdIN0BxFwZoRq8GKUErbbCZ4QKk8YpL 2DbMeboh13q0ONHeGuyheJWVDxaGxT15PLd9t+24FOhKP5iKCUSuAWVjJYGShUk+DfmsPASeuxD l9PJKdJn+qvaYYHD7Vr/TE/WRkxzLLFC4+Y+PCZ8TLW2w== X-Received: by 127.0.0.2 with SMTP id JymDYY7687511xOFaL5VDO1q; Thu, 28 Mar 2024 18:29:00 -0700 X-Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web10.7768.1711675738668989699 for ; Thu, 28 Mar 2024 18:28:59 -0700 X-Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8CxG+lWGQZmiqYgAA--.57232S3; Fri, 29 Mar 2024 09:28:54 +0800 (CST) X-Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxqhJRGQZmDwFtAA--.5941S3; Fri, 29 Mar 2024 09:28:49 +0800 (CST) Message-ID: <9972bb2c-0790-4879-89f3-946574f0d802@loongson.cn> Date: Fri, 29 Mar 2024 09:28:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] [PATCH v2 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg From: "Chao Li" To: devel@edk2.groups.io, ray.ni@intel.com, Gerd Hoffmann Cc: "Kumar, Rahul R" , Sami Mujawar , Sunil V L , Bibo Mao , Dongyan Qian Reply-To: devel@edk2.groups.io,lichao@loongson.cn References: <20240320084152.268323-1-lichao@loongson.cn> <17BFE34457098413.21233@groups.io> <17C02C7EE39BF604.20354@groups.io> In-Reply-To: <17C02C7EE39BF604.20354@groups.io> X-CM-TRANSID: AQAAf8CxqhJRGQZmDwFtAA--.5941S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQALCGYFKmkI+wABsQ X-Coremail-Antispam: 1Uk129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7 ZEXasCq-sGcSsGvfJ3UbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnUUvcSsGvfC2Kfnx nUUI43ZEXa7xR_UUUUUUUUU== 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 Resent-Date: Thu, 28 Mar 2024 18:28:59 -0700 List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: LkJ95uViqg2CT2dGtpIuXeQCx7686176AA= Content-Type: multipart/alternative; boundary="------------IRJosOFC2u8sTIhjOUxskRnY" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=JvqKOLLQ; 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 --------------IRJosOFC2u8sTIhjOUxskRnY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ray, I guess you are very busy recently. If you see this mail, please reply to me, can I can still use the low-high level libraries solution in next commit? Thanks, Chao On 2024/3/26 09:32, Chao Li wrote: > > Hi Ray, > > I responded your comments yesterday, it looks like we have different > opinions on patches 10 and 11, the rest looks fine. > > Could you please consider patches 10 and 11? I think this way is > probably the best solution. I hope this series to be merged as soon as > passable, because the next series is depedent on this series. :) > > Hope to hear back from you! > > On 2024/3/25 11:10, Chao Li wrote: >> >> Hi Ray, >> >> Thank you for reviewing my patch series very carefully. >> >> Here are my comments: >> >> On 2024/3/25 10:46, Ni, Ray wrote: >>> Chao, >>> Thank you for your patience for preparing the new version of patches. >>> However, I still have following minor comments: >>> >>> For patches 1~6: Reviewed-by: Ray Ni >>> For patches 7: can you define meaning of bits in the >>> Attributes/Mask? It seems you are reusing the definitions defined >>> for 7.2.3 EFI_BOOT_SERVICES.GetMemoryMap(). It's fine. But please >>> mention that in comments. Also please use UINT64 for Attributes >>> instead of UINTN. >> Yes, I'm reusing the definitions defined for 7.2.3, I will illustrate >> in the comments next time. About the UINTN, I will fix it next time. >>> For patches 8: Can you rename PcdCpuExceptionVectorBaseAddress to >>> PcdLoongArch64ExceptionVectorBaseAddress and put the PCD >>> definition/reference in the DEC/INF LoongArch64 section? >> OK, I will rename it next time. >>> For patches 9: Please make accordingly changes when you address >>> comments for patch 7. >> OK. >>> For patches 10, 11: Can the lib be avoided if the logic is >>> implemented in CpuDxe driver? >> >> This library is will be called in the PEI stage, so I can't move it >> under the CpuDxe. >> >> This library is the low-level libary of CpuMmuLib, which will consume >> CpuMmuLIb to configure the MMU. >> >> This way is suggested by Laszlo, who saied if CpuMmuLib can not >> content the configure API(high-level libary is the basecal libaray, >> it should not include the configure API), we can split it into two, >> where the hight-livel is CpuMmuLib, and the low-level is CpuMmuInitLib. >> >>> For patch 12(UefiCpuPkg: Add multiprocessor library for >>> LoongArch64): Reviewed-by: Ray Ni >>> For patch 13: Please make accordingly changes when you address >>> comments for patch 8. >> OK. >>> >>> Thanks, >>> Ray >>> ------------------------------------------------------------------------ >>> *From:* Gerd Hoffmann >>> *Sent:* Friday, March 22, 2024 20:39 >>> *To:* Chao Li >>> *Cc:* devel@edk2.groups.io ; Ni, Ray >>> ; Kumar, Rahul R ; Sami >>> Mujawar ; Sunil V L >>> ; Bibo Mao ; Dongyan >>> Qian >>> *Subject:* Re: [PATCH v2 00/13] Part 2 patch set to add LoongArch >>> support into UefiCpuPkg >>> On Wed, Mar 20, 2024 at 04:41:52PM +0800, Chao Li wrote: >>> > This patch set adjusted some order in UefiCpuPig alphabetically, added >>> > LoongArch libraries and drivers into UefiCpuPkg, it is a >>> continuation of >>> > the first patch series v8 submitted at >>> > https://edk2.groups.io/g/devel/message/114526. >>> > >>> > And also separated from https://edk2.groups.io/g/devel/message/116583. >>> > >>> > This series only contents the changes for UefiCpuPkg. >>> > >>> > Patch1-Patch4: Reorder some INF files located in UefiCpuPkg >>> > alphabetically. >>> > >>> > Patch5-Patch13: Added Timer, CpuMmuLib, CpuMmuInitLib, MpInitLib, >>> CpuDxe >>> > for LoongArch, and added some PCD and header files requested by the >>> > above libraries and drivers. >>> > >>> > Modfied modules: UefiCpuPkg >>> > >>> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4726 >>> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734 >>> > >>> > PR: https://github.com/tianocore/edk2/pull/5483 >>> > >>> > V1 -> V2: >>> > 1. Removed PcdCpuMmuIsEnabled. >>> > 2. Removed API GetMemoryRegionAttributes API as it is no longer >>> needed. >>> > 3. Patch3, added two empty line in DXE and PEI INF files. >>> > 4. Patch5, added the Status check in GetTimeInnanoSecond function. >>> > 5. Separated into two series, this is series one, and the second >>> one is >>> > OvmfPkg. >>> >>> While I can't comment on the loongarch architecture details the code >>> and the integration into build system looks overall sane to me. >>> >>> Series: >>> Acked-by: Gerd Hoffmann >>> >>> take care, >>>   Gerd >>> > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117219): https://edk2.groups.io/g/devel/message/117219 Mute This Topic: https://groups.io/mt/105041080/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- --------------IRJosOFC2u8sTIhjOUxskRnY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Ray,

I guess you are very busy recently.

If you see this mail, please reply to me, can I can still use the low-high level libraries solution in next commit?


Thanks,
Chao
On 2024/3/26 09:32, Chao Li wrote:

Hi Ray,

I responded your comments yesterday, it looks like we have different opinions on patches 10 and 11, the rest looks fine.

Could you please consider patches 10 and 11? I think this way is probably the best solution. I hope this series to be merged as soon as passable, because the next series is depedent on this series. :)

Hope to hear back from you!

On 2024/3/25 11:10, Chao Li wrote:

Hi Ray,

Thank you for reviewing my patch series very carefully.

Here are my comments:

On 2024/3/25 10:46, Ni, Ray wrote:
Chao,
Thank you for your patience for preparing the new version of patches.
However, I still have following minor comments:

For patches 1~6: Reviewed-by: Ray Ni <ray.ni@intel.com>
For patches 7: can you define meaning of bits in the Attributes/Mask? It seems you are reusing the definitions defined for 7.2.3 EFI_BOOT_SERVICES.GetMemoryMap(). It's fine. But please mention that in comments. Also please use UINT64 for Attributes instead of UINTN.
Yes, I'm reusing the definitions defined for 7.2.3, I will illustrate in the comments next time. About the UINTN, I will fix it next time.
For patches 8: Can you rename PcdCpuExceptionVectorBaseAddress to PcdLoongArch64ExceptionVectorBaseAddress and put the PCD definition/reference in the DEC/INF LoongArch64 section?
OK, I will rename it next time.
For patches 9: Please make accordingly changes when you address comments for patch 7.
OK.
For patches 10, 11: Can the lib be avoided if the logic is implemented in CpuDxe driver?

This library is will be called in the PEI stage, so I can't move it under the CpuDxe.

This library is the low-level libary of CpuMmuLib, which will consume CpuMmuLIb to configure the MMU.

This way is suggested by Laszlo, who saied if CpuMmuLib can not content the configure API(high-level libary is the basecal libaray, it should not include the configure API), we can split it into two, where the hight-livel is CpuMmuLib, and the low-level is CpuMmuInitLib.

For patch 12(UefiCpuPkg: Add multiprocessor library for LoongArch64): Reviewed-by: Ray Ni <ray.ni@intel.com>
For patch 13: Please make accordingly changes when you address comments for patch 8.
OK.

Thanks,
Ray
From: Gerd Hoffmann <kraxel@redhat.com>
Sent: Friday, March 22, 2024 20:39
To: Chao Li <lichao@loongson.cn>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; Ni, Ray <ray.ni@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>; Sami Mujawar <sami.mujawar@arm.com>; Sunil V L <sunilvl@ventanamicro.com>; Bibo Mao <maobibo@loongson.cn>; Dongyan Qian <qiandongyan@loongson.cn>
Subject: Re: [PATCH v2 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg
 
On Wed, Mar 20, 2024 at 04:41:52PM +0800, Chao Li wrote:
> This patch set adjusted some order in UefiCpuPig alphabetically, added
> LoongArch libraries and drivers into UefiCpuPkg, it is a continuation of
> the first patch series v8 submitted at
> https://edk2.groups.io/g/devel/message/114526.
>
> And also separated from https://edk2.groups.io/g/devel/message/116583.
>
> This series only contents the changes for UefiCpuPkg.
>
> Patch1-Patch4: Reorder some INF files located in UefiCpuPkg
> alphabetically.
>
> Patch5-Patch13: Added Timer, CpuMmuLib, CpuMmuInitLib, MpInitLib, CpuDxe
> for LoongArch, and added some PCD and header files requested by the
> above libraries and drivers.
>
> Modfied modules: UefiCpuPkg
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4726
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734
>
> PR: https://github.com/tianocore/edk2/pull/5483
>
> V1 -> V2:
> 1. Removed PcdCpuMmuIsEnabled.
> 2. Removed API GetMemoryRegionAttributes API as it is no longer needed.
> 3. Patch3, added two empty line in DXE and PEI INF files.
> 4. Patch5, added the Status check in GetTimeInnanoSecond function.
> 5. Separated into two series, this is series one, and the second one is
> OvmfPkg.

While I can't comment on the loongarch architecture details the code
and the integration into build system looks overall sane to me.

Series:
Acked-by: Gerd Hoffmann <kraxel@redhat.com>

take care,
  Gerd

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

You receive all messages sent to this group.

View/Reply Online (#117219) | | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--------------IRJosOFC2u8sTIhjOUxskRnY--