Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Sunil V L

Hi Aaron,

On Fri, Jul 08, 2022 at 08:35:40AM -0600, Aaron Durbin wrote:

I'm top posting with some notes that Furquan helped me put together to
cover the things we've been talking about. We may want to put these and
future notes somewhere else (drive, github, etc) so please let me know what
you think on that front. Also, please add additional thoughts or notes that
were missed.
Since the ECRs need to be submitted as word doc,
the plan was to archive the notes/comments and ECR versions in the
gdrive itself. Please visit

External people(non-members) can raise issues in github also.

Some high level notes:

- The current proposed ECRs live in the very early (form a boot
standpoint) portion of ACPI. These are needed to easily identify
information for the purposes of booting a kernel. These tables are required
because they can be easily read prior to the ACPI namespace being brought
up. To that end, we should assess the information in each of these early
tables from a "is this required to boot?". Else, we can move to ACPI
namespace proper.
- Are there thoughts on what would live in the ACPI namespace? If there
are already ideas on that, I think we should put those forward.
- We should more thoroughly document in what is required and what
field values from the required information is optional/static, etc. It'll
end up being a more thorough spec to direct people to build out the ACPI
data consistently across implementations. I think this is largely an
exercise of going through each data structure and call out fields that are
RISC-V specific.
Will update the guidance doc.

- Not entirely unrelated, but what combinations of UEFI, ACPI, and
DeviceTree do we expect? Are we inherently saying UEFI is always present,
and it's an option to utilize ACPI or DeviceTree? This is asked because it
establishes what the dependencies are for gathering certain sets of
information. AIA last bullet point alludes to this in how and what
information is conveyed where.
UEFI supports both DT and ACPI. But ACPI is supported only with UEFI
(leaving legacy x86 BIOS).


- ISA string and extension nodes
- Currently, the organization of RHCT assumes two types of “extensions”
- Boolean based: That can be indicated by presence of ISA string in ISA
string node
- Parameter based: That requires some additional parameters to be passed
in along with the ISA string presence. Example: CBO.
- However, this distinction adds an overhead in terms of ACPI ECRs that
need to pushed out for every extension that is parameter based since it
will require its own table e.g. CMO extension node. This also requires
another system for creating and managing these table names, structures
outside of RVI.
- An alternate approach would be to standardize on the naming/strings
for different extension attributes and utilize that to drive software
enumeration. Example: Zicbom, Zicbop, Zicboz, Zicbo64. Out of these, the
first three are already defined. With the addition of the 4th string that
defines the cache block size, we can eliminate the need for the CMO
extension node.
- However, this requires agreement at the RVI level to converge on the
string naming for these different attributes. Aaron sent out an email to
start that discussion:
- Our goal should be to reduce the roundtrip in terms of ECRs that are
required for every new extension. If we can create a pointer within ACPI
and maintain rest of the stuff in RVI, then it can help accelerate the
Not every new extension would need additional parameters to be passed.
So far, we have only CBO (as far as I can found) out of all ratified
extensions. So, it is less frequent and I think multiple ECRs is not an overhead.
Even if we maintain within RVI, I think it may take same/more time and effort
to ratify each version of that document.


- Divided into two ECRs since IMSIC information (base address and size)
are being added to RINTC to define “interrupt controller”. However, AIA
spec is not yet frozen. So, need to decide whether we should send it as a
single ECR or first send a minimal ECR for RINTC and then follow-up with a
change to add IMSIC details to it once AIA spec is frozen.
- RINTC “IMSIC Size” needs to be explicit that the size includes the
size of S and G level interrupt files. This should be mentioned in prose
instead of reference to guest index bits.
- HartID is being placed in RINTC instead of RHCT because it matches
what ARM and x86 do. No strong opinions about one or the other, but just
keeping it in RINTC for consistency.
- We should evaluate what structures are required pre-ACPI and what can
be processed and handled later as part of ACPI enumeration.


- Need to decide what the mandatory structures would be to support
variety of combinations:
- IMSIC but no APLIC
- APLIC but no IMSIC
- For the case of IMSIC but no APLIC, the IMSIC structure in AIA ECR is
mostly don't care. The only required field in it is the number of
supervisor/guest mode interrupt identities. If this can be pulled up into
RINTC, then the entire IMSIC structure can be made optional. The fields for
guest/hart/group index are primarily required for the case where IMSIC +
APLIC is supported. This would lead to some duplication at the RINTC level
since all harts would typically have the same number of interrupt files at
supervisor and guest mode, but that might be an okay thing to live with.
As Anup mentioned, we need single MSI controller structure.

- Need to elaborate what fast and slow IPI mean in the ECR. This is
primarily to cover the case where IMSIC is being emulated by the hypervisor
and so broadcast IPIs using IMSIC would be slower than SBI.
Will update.

- Model in IMSIC structure needs more elaboration. The way it is
currently defined requires every vendor to reserve a model ID for their
IMSIC with Can we explore the ideas of using a vendor string
or vendor:device:impl ids for IMSIC that can eliminate the need to make a
roundtrip through for the model?
We can add manufacturer ID and revision ID combination so that we don't
need to send ECRs.



On Tue, Jul 5, 2022 at 11:16 AM Sunil V L <sunilvl@...> wrote:

Hi All,

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:
a) MADT - AIA RINTC (version 2) :
b) MADT - AIA IMSIC/APLIC version 2:

PoC Code has been updated at same location as earlier.


On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via
Hi All,

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 -
edk2 -
edk2-platforms -
linux -

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 2022.
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.


Join to automatically receive all group messages.