On Jul 8, 2022, at 7:35 AM, Aaron Durbin <adurbin@...> wrote:



Hi,

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.

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 https://github.com/riscv-non-isa/riscv-acpi 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.
• 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.

RHCT

• 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: https://lists.riscv.org/g/tech-os-a-see/message/66
• 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 effort.

RINTC

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

AIA

• Need to decide what the mandatory structures would be to support variety of combinations:
• IMSIC but no APLIC
• APLIC but no IMSIC
• IMSIC and APLIC
• 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.
• 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.
• 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 uefi.org. 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 uefi.org for the model?

-Aaron

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:
        https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
        b)MADT RINTC - version 2:
        https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
2) AIA ECRs
        a)  MADT - AIA RINTC (version 2) :
        https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
        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.

Thanks
Sunil

On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org wrote:
> 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 -                                                                                                                                                                     
> https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing
>
> 2) Add new RISC-V Hart Capabilities Table (RHCT).
> https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing
>
> 3) Add AIA interrupt controllers in MADT table
> https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing
>
> 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 frozen.
>
> 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
> edk2-platforms - https://github.com/ventanamicro/edk2-platforms/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 -
> https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel
>                                                                                                                                                                                                           
> 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.
>                                                                                                                                                                                                           
> Thanks!
> Sunil
>
>
>
>
>

just a reminder that we should be moving to unified discovery during boot to feed everything. not isa strings. not csrs.

--------
sent from a mobile device. please forgive any typos.

On Jul 8, 2022, at 7:35 AM, Aaron Durbin <adurbin@...> wrote:


Hi,

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.

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 https://github.com/riscv-non-isa/riscv-acpi 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.
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.



RHCT

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: https://lists.riscv.org/g/tech-os-a-see/message/66
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 effort.

RINTC

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.

AIA

Need to decide what the mandatory structures would be to support variety of combinations:

IMSIC but no APLIC
APLIC but no IMSIC
IMSIC and APLIC

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.
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.
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 uefi.org. 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 uefi.org for the model?


-Aaron


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:
https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
b)MADT RINTC - version 2:
https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
2) AIA ECRs
a) MADT - AIA RINTC (version 2) :
https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
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.

Thanks
Sunil

On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org wrote:

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 -
https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

2) Add new RISC-V Hart Capabilities Table (RHCT).
https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

3) Add AIA interrupt controllers in MADT table
https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

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

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
edk2-platforms - https://github.com/ventanamicro/edk2-platforms/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 -
https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

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.

Thanks!
Sunil

On Jul 8, 2022, at 7:48 AM, Philipp Tomsich <philipp.tomsich@...> wrote:

Unified DIscovery is expected to be used by firmware to populate DT
and ACPI/UEFI tables.

Philipp.

On Fri, 8 Jul 2022 at 16:47, Mark Himelstein <markhimelstein@...> wrote:

just a reminder that we should be moving to unified discovery during boot to feed everything. not isa strings. not csrs.

--------
sent from a mobile device. please forgive any typos.

On Jul 8, 2022, at 7:35 AM, Aaron Durbin <adurbin@...> wrote:


Hi,

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.

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 https://github.com/riscv-non-isa/riscv-acpi 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.
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.



RHCT

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: https://lists.riscv.org/g/tech-os-a-see/message/66
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 effort.

RINTC

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.

AIA

Need to decide what the mandatory structures would be to support variety of combinations:

IMSIC but no APLIC
APLIC but no IMSIC
IMSIC and APLIC

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.
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.
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 uefi.org. 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 uefi.org for the model?


-Aaron

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:
https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
b)MADT RINTC - version 2:
https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
2) AIA ECRs
a) MADT - AIA RINTC (version 2) :
https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
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.

Thanks
Sunil

On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org wrote:

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 -
https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

2) Add new RISC-V Hart Capabilities Table (RHCT).
https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

3) Add AIA interrupt controllers in MADT table
https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

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

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
edk2-platforms - https://github.com/ventanamicro/edk2-platforms/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 -
https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

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.

Thanks!
Sunil