From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mx.groups.io with SMTP id smtpd.web10.47006.1584940383830400585 for ; Sun, 22 Mar 2020 22:13:03 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.115, mailfrom: ray.ni@intel.com) IronPort-SDR: 3zp7BBoDcfIsoGnGJyZBk2mcNWNhu0mjgmO/rFu2Zzk3hSJM6CobGkbCRQcQLbV2aj0Jk3IGXo QGh1ft4h5Drw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2020 22:13:03 -0700 IronPort-SDR: AOPi0kZUQlm7ps7umGRhxXegvY+8rQIWpuswlv3solHfuIAY19lMCrovJLBenoK1IjnDmHRVau a6jvkqKzHagw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,295,1580803200"; d="scan'208,217";a="356991872" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga001.fm.intel.com with ESMTP; 22 Mar 2020 22:13:03 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 22 Mar 2020 22:13:02 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sun, 22 Mar 2020 22:13:02 -0700 Received: from shsmsx107.ccr.corp.intel.com (10.239.4.96) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Sun, 22 Mar 2020 22:13:02 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.206]) by SHSMSX107.ccr.corp.intel.com ([169.254.9.232]) with mapi id 14.03.0439.000; Mon, 23 Mar 2020 13:12:59 +0800 From: "Ni, Ray" To: "Chang, Abner (HPS SW/FW Technologist)" , "devel@edk2.groups.io" CC: "Kinney, Michael D" , "Schaefer, Daniel (DualStudy)" , "Chen, Gilbert" Subject: Re: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Thread-Topic: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Thread-Index: AdX+ln/63mRZNDhhSlaiQ/rb3bppEQCLz/wwAAJ2NQA= Date: Mon, 23 Mar 2020 05:12:59 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C4A74A2@SHSMSX104.ccr.corp.intel.com> References: <734D49CCEBEEF84792F5B80ED585239D5C4A2E4C@SHSMSX104.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: ray.ni@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_734D49CCEBEEF84792F5B80ED585239D5C4A74A2SHSMSX104ccrcor_" --_000_734D49CCEBEEF84792F5B80ED585239D5C4A74A2SHSMSX104ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resend to devel@edk2.groups.io with my respons= es. announce@edk2.groups.io is not for tech dis= cussion and only few people have post permission. From: Chang, Abner (HPS SW/FW Technologist) Sent: Monday, March 23, 2020 12:05 PM To: Ni, Ray ; announce@edk2.groups.io Cc: Kinney, Michael D ; Schaefer, Daniel (DualS= tudy) ; Chen, Gilbert Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Ray, my responses in line. From: Ni, Ray [mailto:ray.ni@intel.com] Sent: Friday, March 20, 2020 5:05 PM To: announce@edk2.groups.io Cc: Chang, Abner (HPS SW/FW Technologist) >; Kinney, Michael D >; Ni, Ray > Subject: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Topic: 1. EDK2 DxeIpl Abstraction (Abner Chang/HPE) Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20Dx= eIpl%20Abstraction.pdf Today's meeting was extended to 2 hours to discuss the overall RISC-V suppo= rt in EDKII. It makes sense because low-level design depends on the finaliz= e of high-level design. Today's RISC-V enabling in EDKII work is to provide a UEFI wrapper over RIS= C-V OpenSBI (Open Source Supervisor Binary Interface), which is an open-sou= rce reference implementation (https://github.com/riscv/opensbi) of RISC-V S= BI specification (https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-= sbi.adoc). OpenSBI itself is a boot loader. If RISC-V SBI specification is treated as = UEFI spec and OpenSBI is treated as the EDKII. Right now, Abner's work is the only effort that enables UEFI in RISC-V plat= forms. The EDKII RISC-V environment consists of three phases: SEC-PEI-DXE. A RISC-= V specific SEC module statically linked with OpenSBI exposes all interfaces= required by the UEFI wrapper. There are 3 sub-topics discussed in the meeting: 1. Which mode DXE phase is running at? RISC-V defines three privileged modes: Machine/Supervisor/User Mode. SEC and PEI run in M mode and DXE can run either in M mode or S mode whi= ch is the platform's choice. If DXE runs in S mode, some of the resources cannot be accessed. UEFI spec says RISC-V only runs in M mode during post including DXE. Spe= c needs update. [Abner] Yes, this must be updated. I will take this. 2. How to resolve MdeModulePkg's dependency on RiscVPkg? The dependency is because the M to S mode switch [Abner] This may not accurate. I think you mean the dependency is exposed d= ue to we rely on RISC-V OpenSBI execution mode switch function to put DXE p= hase in Supervisor mode. We should fix the issue which DXE IPL mixes up the= processor architecture in itself, but not to fix switch mode itself. [Ray] Your words are more accurate. But if we split the change to 2 parts: = one requires DXE phase runs in M mode, the other requires DXE phase runs in= S mode. Only the 2nd part introduces the MdeModulePkg's dependency on Risc= VPkg. We could potentially work on the first part (when the final conclusio= n is RISC-V does need SEC and PEI phases for UEFI). Abner's solution tries to address this dependency issue by introducing a= nother abstract layer. (see slides: https://edk2.groups.io/g/devel/files/De= signs/2020/0320/EDK2%20DxeIpl%20Abstraction.pdf) Mike proposes another solution: RiskVPkg exposes the mode switch interfa= ces (sbi_init ?) through PPI and the PPI definition can be in MdePkg which = might be included by PI spec. [Abner] This may not work if the PPI/Protocol still have dependency with RI= SC-V definitions. But it is ok if could we define a generic PPI/Protocol su= ch as EFI_EXECUTION_MODE_PROTOCOL(PPI) under MdePkg. Then arch provides the= implementation, however, this is our midterm plan not for now though. NULL= instance of DxeIplHadndoffLib is still a neat choice IMO. [Ray] The original plan was to expose OpenSBI interfaces through PPI/Protoc= ol defined in PI spec and MdePkg. But given the fact OpenSBI is an under-de= velopment project and your change is a UEFI wrapper over OpenSBI, it may be= hard to propose the OpenSBI interfaces to PI spec. There was an idea raise= d in the meeting which is to extend UefiPayloadPkg for RISC-V. 3. Location of RiscVPkg and RiscVPlatformPkg RiscVPkg in @edk2-platforms/Silicon/... directory. RiscVPlatformPkg in @edk2-platforms/Platform/... directory. Long term goal is to put all CPU implementation that follows industry st= andard to UefiCpuPkg, including ARM and RISC-V. [Abner] We can consider this solution to put RISC-V packages in edk2-platfo= rms in temporary. However, the final decision should be made accroding, 1. The plan for refining UefiCpuPkg. It is meaningless to put RISC-V pac= kages in edk2-platforms if the plan of UefiCpuPkg refining is something lik= e one or two years. 2. How far it is from current UefiCpuPkg implementation to the ideal gen= eric UefiCpuPkg for all archs? [Ray] RiscVPlatformPkg in @edk2-platforms doesn't depend on above 2 questio= ns. 4. Which changes can be in edk2 Need Abner to look at all the changes again. But at least the INF/C chan= ges that enable individual drivers to be built by RISC-V compiler can. [Abner] yes. Thanks, Ray --_000_734D49CCEBEEF84792F5B80ED585239D5C4A74A2SHSMSX104ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resend to de= vel@edk2.groups.io with my responses.

 

announce@= edk2.groups.io is not for tech discussion and only few people have post= permission.

 

From: Chang, Abner (HPS SW/FW Technologist) &= lt;abner.chang@hpe.com>
Sent: Monday, March 23, 2020 12:05 PM
To: Ni, Ray <ray.ni@intel.com>; announce@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Schaefer, = Daniel (DualStudy) <daniel.schaefer@hpe.com>; Chen, Gilbert <gilbe= rt.chen@hpe.com>
Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 20= 20

 

Ray, my responses in l= ine.

 

From: Ni, Ray [mailto:ray.ni@intel.com]
Sent: Friday, March 20, 2020 5:05 PM
To: announce@edk2.groups.= io
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Kinney, Michael D <michael.d.kinney@intel.com>; = Ni, Ray <ray.ni@intel.com> Subject: TianoCore Community Design Meeting Minutes - Mar 20, 2020

 

Topic:

 

1. EDK2 DxeIpl Abstraction (Abner Chang/HPE)

 

   Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abst= raction.pdf

 

 

 

Today's meeting was extended to 2 hours to discuss t= he overall RISC-V support in EDKII. It makes sense because low-level design= depends on the finalize of high-level design.

 

Today's RISC-V enabling in EDKII work is to provide = a UEFI wrapper over RISC-V OpenSBI (Open Source Supervisor Binary Interface= ), which is an open-source reference implementation (https://github.com/riscv/opensbi) of RISC-V SBI specification (https://github.com/riscv/riscv-sbi-doc/blo= b/master/riscv-sbi.adoc).

 

OpenSBI itself is a boot loader. If RISC-V SBI speci= fication is treated as UEFI spec and OpenSBI is treated as the EDKII.<= /o:p>

 

Right now, Abner's work is the only effort that enab= les UEFI in RISC-V platforms.

 

The EDKII RISC-V environment consists of three phase= s: SEC-PEI-DXE. A RISC-V specific SEC module statically linked with OpenSBI= exposes all interfaces required by the UEFI wrapper.

 

There are 3 sub-topics discussed in the meeting:

 

1. Which mode DXE phase is running at?

 

   RISC-V defines three privileged modes: = Machine/Supervisor/User Mode.

   SEC and PEI run in M mode and DXE can r= un either in M mode or S mode which is the platform's choice.

   If DXE runs in S mode, some of the reso= urces cannot be accessed.

   UEFI spec says RISC-V only runs in M mo= de during post including DXE. Spec needs update.

[Abner] Yes, thi= s must be updated. I will take this.

 

2. How to resolve MdeModulePkg's dependency on RiscV= Pkg?

 

   The dependency is because the M to S mo= de switch

[Abner] This may= not accurate. I think you mean the dependency is exposed due to we rely on= RISC-V OpenSBI execution mode switch function to put DXE phase in Supervis= or mode. We should fix the issue which DXE IPL mixes up the processor architecture in itself, but not to fix swit= ch mode itself.

[Ray] Your words are more accurate. But if we = split the change to 2 parts: one requires DXE phase runs in M mode, the oth= er requires DXE phase runs in S mode. Only the 2nd part introduc= es the MdeModulePkg’s dependency on RiscVPkg. We could potentially work on the first part (when the final conc= lusion is RISC-V does need SEC and PEI phases for UEFI).=

 

   Abner's solution tries to address = this dependency issue by introducing another abstract layer. (see slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abst= raction.pdf)

   Mike proposes another solution: RiskVPk= g exposes the mode switch interfaces (sbi_init ?) through PPI and the PPI d= efinition can be in MdePkg which might be included by PI spec.

[Abner] This may= not work if the PPI/Protocol still have dependency with RISC-V definitions= . But it is ok if could we define a generic PPI/Protocol such as EFI_EXECUT= ION_MODE_PROTOCOL(PPI) under MdePkg. Then arch provides the implementation, however, this is our midterm plan n= ot for now though. NULL instance of DxeIplHadndoffLib is still a neat choic= e IMO.

[Ray] The original plan was to expose OpenSBI = interfaces through PPI/Protocol defined in PI spec and MdePkg. But given th= e fact OpenSBI is an under-development project and your change is a UEFI wr= apper over OpenSBI, it may be hard to propose the OpenSBI interfaces to PI spec. There was an idea raised in = the meeting which is to extend UefiPayloadPkg for RISC-V.

 

3. Location of RiscVPkg and RiscVPlatformPkg

 

   RiscVPkg in @edk2-platforms/Silicon/...= directory.

   RiscVPlatformPkg in @edk2-platforms/Pla= tform/... directory.

   Long term goal is to put all CPU implem= entation that follows industry standard to UefiCpuPkg, including ARM and RI= SC-V.

[Abner] We can c= onsider this solution to put RISC-V packages in edk2-platforms in temporary= . However, the final decision should be made accroding,

  1. The plan for refining UefiCpuPkg. It is meaningless to put RISC-V pac= kages in edk2-platforms if the plan of UefiCpuPkg refining is something lik= e one or two years.
  2. How far it is from current UefiCpuPkg implementation to the ideal gen= eric UefiCpuPkg for all archs?

[Ray] RiscVPlatformPkg in @edk2-platforms does= n’t depend on above 2 questions.

 

4. Which changes can be in edk2

 

   Need Abner to look at all the changes a= gain. But at least the INF/C changes that enable individual drivers to be b= uilt by RISC-V compiler can.

[Abner] yes.

 

Thanks,

Ray

  

--_000_734D49CCEBEEF84792F5B80ED585239D5C4A74A2SHSMSX104ccrcor_--