On Thu, Aug 04, 2022 at 09:16:21AM -0600, Aaron Durbin wrote:
On Wed, Aug 3, 2022 at 8:17 AM Sunil V L <sunilvl@...> wrote:
We plan to send below two ECRs to UEFI forum on 08/08/2022. These two
ECRs don't have any dependency on any unfrozen specs.
Getting these two ECRs accepted by UEFI forum would help us to enable big
chunk of ACPI infrastructure patches for RISC-V.
I don't think we should submit this one until we settle on how we convey
behaviors outside of an ISA string. I suspect that will change so we should
anticipate that. Right now we have ISA string plus CMO parameters as
specific RHCT Nodes. Are we concerned about timing on adoption to push this
in its current form? I ask because I'd rather not have this set in stone
only for us to quickly come back and say "stop using these fields. we have
a new node/mechanism to convey this information". What do you think?
I was under the impression that it is decided not to use the
extension names mentioned in profile spec. Sorry I didn't know you are
still working with TSC to conclude on this.
In that case, let's remove the CMO structure from the RHCT and submit
the ECR. CMO structure is not really mandatory for OS.
I brought up this topic in the TSC meeting this week as I indicated I
would. I need to work with some others to formalize the direction, but
that's going to take a little more time.
Right. My preference is, to keep sending multiple revisions of the ECRs
with incremental changes, while making sure we don't obsolete things
fairly quickly as you mentioned. I think removing CMO strucutre helps us
to take care of both requirements. When you get clarity from TSC, we can
add in next revision. What do you think?
Aside from maybe wordsmithing a little more for clarity purposes (based on
commentary) I think this one seems fine from my standpoint.
Please feel free to provide comments in the document before 08/08.
The documents and feedback will be archived in the same folder.
On Tue, Jul 05, 2022 at 10:46:18PM +0530, Sunil V L via lists.riscv.org
Thanks a lot for great feedback over last week on the ECRs. I have
created version 2 of the ECRs addressing most of the comments. We will be
discussing this version of the ECRs in this week's meeting. Please
provide your comments in this version of the documents.
1) Non-AIA ECRs
a) RHCT - version 2:
b)MADT RINTC - version 2:https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
2) AIA ECRshttps://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
a) MADT - AIA RINTC (version 2) :
b) MADT - AIA IMSIC/APLIC version 2:https://docs.google.com/document/d/1zDainvcxD14eawsyc3y1s78zP7ruefyGzcsP1bBak3w/edit?usp=sharing
PoC Code has been updated at same location as earlier.
On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org
Please review below Engineering Change Request (ECR) to update the ACPI
spec for enabling basic ACPI support for RISC-V.
1) Add INTC structure in MADT Table -
2) Add new RISC-V Hart Capabilities Table (RHCT).
3) Add AIA interrupt controllers in MADT table
First two ECRs do not have a dependency on any RVI specs which are not
frozen. But the third ECR has a dependency on AIA spec to be frozen.
Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is
The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
platform. Below are links to the source code for the PoC.
qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
linux - https://github.com/ventanamicro/linux/tree/dev-upstream
You can find how to build and test these changes in this link -
You can provide the feedback by commenting in the document itself. I am
hoping to send at least first two ECRs to UEFI forum by 8th August
So, appreciate your help to improve these ECRs before 4th August 2022
(45 days from today).
Feel free to reach out if you have any questions.