Date   

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:
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.
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
https://github.com/riscv-non-isa/riscv-acpi/wiki/ACPI-ASWG-ECR-Process.

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




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


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.
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 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?
We can add manufacturer ID and revision ID combination so that we don't
need to send ECRs.

Thanks
Sunil



-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












Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Greg Favor
 

To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.

The combinatorics of taking every optional behavior, every parameter that can take on a set of possible values, and every WARL field and the allowed range of possibilities, and then creating an "extension" name for every individual possible "key- value" pair are crazy.  (This is why people instead use key-value representations.)

For Profiles, these names have been created on an as-needed basis for specific "key-value" pairs, and no further.  Their motivation was to simply have acronymic "extension" names for each of these line items.

In contrast, discovery schemes - like Device Tree, ACPI, and RISC-V Unified Discovery - want something distinctly different.  Namely standard "key" names for options, parameters, and WARL fields; standard names for the values of a "key"; and a schema for representing a set of key-value pairs.

Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

Lastly, I think everyone would agree that option / parameter / WARL field names, and their associated value names, are not "extensions".  And hence should not be mixed up with the "extension" names created and used in Profiles.  Any standardization of "key" names and "value" names should simply focus on usage in discovery schemes (i.e. DT, ACPI, UD).  This needs to support all possible key-value pairs.

As to whether all these acronymic line items or "key-value" pairs in Profiles are "extensions", there is probably contention, but I would at least say that these are not extensions in the usual sense.  And they should exist and arise solely in the context of Profiles (for the intended purpose of giving an extension-like acronymic name to each line item).

In short, I would suggest that it is probably best to keep discussion of these two topics separate.

Greg


On Fri, Jul 8, 2022, 1:30 PM Allen Baum <allen.baum@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
 (which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented). 
So these are constraints on the spec'ed options that are required to run SW on the platform.


On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron


Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Allen Baum
 

I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example).
Who is the consumer of that identifier? Is this a value you would expect to be encoded in the config-struct of on-line discovery?
I am building a list of all architectural options that aren't controlled by CSR fields, for what it is worth, 
as well as all the named option value ranges, regardless of whether they're controlled by a CSR value or not.
The intent of this is to be able to configure the Sail model to implement the behavior they control.

On Fri, Jul 8, 2022 at 1:30 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
 (which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented). 
So these are constraints on the spec'ed options that are required to run SW on the platform.


On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron


Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Allen Baum
 

If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
 (which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented). 
So these are constraints on the spec'ed options that are required to run SW on the platform.


On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron


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

Ved Shanbhogue
 

On Fri, Jul 08, 2022 at 08:58:56AM -0700, Mark Himelstein wrote:
Just that UD is the source for filling in everything. In my words
foundational and not just orthogonal. I didn't see it below in, for
example, discussions about ISA strings. I wanted to make sure that whether
it be ACPI or DT or something else, they all are created from UD as the
source.
Got it. I understand what you are saying now and agree.

regards
ved


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

Anup Patel
 

Hi Aaron,

Few comments below ...

On Fri, Jul 8, 2022 at 8:05 PM 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.
Rather than gating these ACPI ECR efforts on AIA spec being frozen. We
should start sending out incremental ECRs for the things that are
already ratified. Each ECR will be reviewed separately on the
UEFI/ACPI forums which will take its own time.

For the next few years, we will certainly see a continuous stream of
ECRs being sent-out at regular intervals.

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.
The IMSIC global structure cannot be made optional because it is used
to probe the IMSIC driver. On similar lines, various RINTC structures
are used to probe the INTC driver.
Also, moving fields from IMSIC global structure to RINTC structure
just duplicates information without any simplification for software.

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







Regards,
Anup


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

Heinrich Schuchardt
 

On 7/8/22 17:58, mark wrote:
Just that UD is the source for filling in everything. In my words foundational and not just orthogonal. I didn't see it below in, for example, discussions about ISA strings. I wanted to make sure that whether it be ACPI or DT or something else, they all are created from UD as the source.
Without wording about this below, readers are left to their own to figure out how to get to the ISA string or DT. I am suggesting that we need a reference in the prose below that says all existence items emanate from UD and that all software uses UD to populate their data structures.
Does this make sense?
Mark

Does the Unified DIscovery Specification exit yet? Where can I find it?

Best regards

Heinrich


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

mark
 

Just that UD is the source for filling in everything. In my words foundational and not just orthogonal. I didn't see it below in, for example, discussions about ISA strings. I wanted to make sure that whether it be ACPI or DT or something else, they all are created from UD as the source.

Without wording about this below, readers are left to their own to figure out how to get to the ISA string or DT. I am suggesting that we need a reference in the prose below that says all existence items emanate from UD and that all software uses UD to populate their data structures.

Does this make sense?

Mark

On Fri, Jul 8, 2022 at 8:44 AM Ved Shanbhogue <ved@...> wrote:
I think of UD being orthogonal to this discussion.

      Firmware world           |   OS world
                               |
[UD, etc. ]---firmware builds-+->[ACPI/DT]--->OS
                               |
                               |

So the comments about early boot etc. in this thread I read as referring
to the OS world. Or was the suggestion that UD be extended to S mode and
we get away with all ACPI/DT enumeration?

regards
ved

On Fri, Jul 08, 2022 at 08:31:23AM -0700, mark wrote:
>agreed. but it all starts with UD.
>
>we had every extension devising their own discovery mechanism and everyone agreed that was not the correct thing to do.
>
>We reduced UD this year to just ASN and extension existence .  It should be doable but there is some drag from the past incarnation we are all working through.
>
>Mark
>
>--------
>sent from a mobile device. please forgive any typos.
>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>
>
>
>


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

Philipp Tomsich <philipp.tomsich@...>
 

I would also expect to have the OS make the UD message (in its raw, unparsed form) available to userspace consumers.
In other words: even if the OS works off DT/ACPI tables, the full information should be passed through (even if only for debug tools that may want to capture additional info).

Philipp.

On Fri, 8 Jul 2022 at 17:54, Atish Kumar Patra <atishp@...> wrote:


On Fri, Jul 8, 2022 at 8:44 AM Ved Shanbhogue <ved@...> wrote:
I think of UD being orthogonal to this discussion.

      Firmware world           |   OS world
                               |
[UD, etc. ]---firmware builds-+->[ACPI/DT]--->OS
                               |
                               |

So the comments about early boot etc. in this thread I read as referring
to the OS world. Or was the suggestion that UD be extended to S mode and
we get away with all ACPI/DT enumeration?

As per my understanding, early boot refers to OS world. Introducing UD to the S-mode is not an option in my opinion. We already have all the infrastructure for DT/ACPI in rich OS land. As Phillip pointed out, the plan was always to update the DT/ACPI tables by layers below the OS by looking at the UD(only necessary information).


regards
ved

On Fri, Jul 08, 2022 at 08:31:23AM -0700, mark wrote:
>agreed. but it all starts with UD.
>
>we had every extension devising their own discovery mechanism and everyone agreed that was not the correct thing to do.
>
>We reduced UD this year to just ASN and extension existence .  It should be doable but there is some drag from the past incarnation we are all working through.
>
>Mark
>
>--------
>sent from a mobile device. please forgive any typos.
>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>
>
>
>


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

atishp@...
 



On Fri, Jul 8, 2022 at 8:44 AM Ved Shanbhogue <ved@...> wrote:
I think of UD being orthogonal to this discussion.

      Firmware world           |   OS world
                               |
[UD, etc. ]---firmware builds-+->[ACPI/DT]--->OS
                               |
                               |

So the comments about early boot etc. in this thread I read as referring
to the OS world. Or was the suggestion that UD be extended to S mode and
we get away with all ACPI/DT enumeration?

As per my understanding, early boot refers to OS world. Introducing UD to the S-mode is not an option in my opinion. We already have all the infrastructure for DT/ACPI in rich OS land. As Phillip pointed out, the plan was always to update the DT/ACPI tables by layers below the OS by looking at the UD(only necessary information).


regards
ved

On Fri, Jul 08, 2022 at 08:31:23AM -0700, mark wrote:
>agreed. but it all starts with UD.
>
>we had every extension devising their own discovery mechanism and everyone agreed that was not the correct thing to do.
>
>We reduced UD this year to just ASN and extension existence .  It should be doable but there is some drag from the past incarnation we are all working through.
>
>Mark
>
>--------
>sent from a mobile device. please forgive any typos.
>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>
>
>
>


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

Ved Shanbhogue
 

I think of UD being orthogonal to this discussion.

Firmware world | OS world
|
[UD, etc. ]---firmware builds-+->[ACPI/DT]--->OS
|
|

So the comments about early boot etc. in this thread I read as referring
to the OS world. Or was the suggestion that UD be extended to S mode and
we get away with all ACPI/DT enumeration?

regards
ved

On Fri, Jul 08, 2022 at 08:31:23AM -0700, mark wrote:
agreed. but it all starts with UD.

we had every extension devising their own discovery mechanism and everyone agreed that was not the correct thing to do.

We reduced UD this year to just ASN and extension existence . It should be doable but there is some drag from the past incarnation we are all working through.

Mark

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

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











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

mark
 

agreed. but it all starts with UD.

we had every extension devising their own discovery mechanism and everyone agreed that was not the correct thing to do.

We reduced UD this year to just ASN and extension existence . It should be doable but there is some drag from the past incarnation we are all working through.

Mark

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

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








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

Philipp Tomsich <philipp.tomsich@...>
 

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








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

mark
 

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






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

Aaron Durbin
 

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






Direction of Identifying Extensions

Aaron Durbin
 

Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron


Re: Review request for ACPI ECRs

Sunil V L
 

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





Re: [RISC-V] [tech-aia] Invitation: Ad-hoc ACPI ECR Review meeting - Part 2 @ Mon Jul 4, 2022 9:30pm - 10:30pm (IST) (tech-aia@lists.riscv.org)

Ved Shanbhogue
 

Sunil Hi -
July 4 is a holiday in the US. COuld we meet on 5th?
regards
ved

On Tue, Jun 28, 2022 at 11:34 AM Sunil V L <sunilvl@...> wrote:

You have been invited to the following event.

Ad-hoc ACPI ECR Review meeting - Part 2

When
Mon Jul 4, 2022 9:30pm – 10:30pm India Standard Time - Kolkata
Joining info
Join with Google Meet
Join by phone
(US) +1 484-641-8341 (PIN: 271065128)
Calendar
Who
sunilvl@... - organizer
Atish Kumar Patra
Hi All,

This is the second part of the ACPI ECR review meeting to cover remaining things. Many thanks to the people who joined the first meeting and provided valuable feedback. Let us meet again and discuss further.

Meeting Info:

Going (tech-aia@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tech-aia@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


Invitation: Ad-hoc ACPI ECR Review meeting - Part 2 @ Mon Jul 4, 2022 9:30pm - 10:30pm (IST) (tech-unixplatformspec@lists.riscv.org)

Sunil V L
 

You have been invited to the following event.

Ad-hoc ACPI ECR Review meeting - Part 2

When
Mon Jul 4, 2022 9:30pm – 10:30pm India Standard Time - Kolkata
Joining info
Join with Google Meet
Join by phone
(US) +1 484-641-8341 (PIN: 271065128)
Calendar
tech-unixplatformspec@...
Who
sunilvl@... - organizer
tech-unixplatformspec@...
tech-os-a-see@...
tech-aia@...
Atish Kumar Patra
furquan@...
apatel@...
ksankaran@...
Hi All,

This is the second part of the ACPI ECR review meeting to cover remaining things. Many thanks to the people who joined the first meeting and provided valuable feedback. Let us meet again and discuss further.

Meeting Info:
  • Meeting link: https://zoom.us/j/7237830759    
  • Passcode: 741796    
  • Join link: https://zoom.us/j/7237830759?pwd=bGE2QkMwNm1xclF4SDI1cll0Mk1LQT09 
  • Going (tech-unixplatformspec@...)?   Yes - Maybe - No    more options »

    Invitation from Google Calendar

    You are receiving this courtesy email at the account tech-unixplatformspec@... because you are an attendee of this event.

    To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar.

    Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


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

    Sunil V L
     

    In case the meeting details are not reflecting in the invite, here is
    the info:

    Meeting link: https://zoom.us/j/7237830759
    Passcode: 741796
    Join link: https://zoom.us/j/7237830759?pwd=bGE2QkMwNm1xclF4SDI1cll0Mk1LQT09

    Thanks
    Sunil

    On Fri, Jun 24, 2022 at 03:42:14PM +0400, Furquan Shaikh wrote:
    On Fri, Jun 24, 2022 at 8:31 AM Sunil V L <sunilvl@...> wrote:

    On Thu, Jun 23, 2022 at 11:30:28PM +0400, Furquan Shaikh wrote:
    Hello Sunil,

    Thanks for sending out these ECRs. After looking at these documents,
    we have a lot of comments/questions, but I think it might be
    productive to walk through the assumptions and approach for defining
    these structures over a meeting with interested RISC-V members. What
    do you think?
    Hi Furquan,

    Yes, let's do that. I will setup a meeting on Monday 27th 2022. We can
    continue the discussion later if we can not finish in an hour.
    Sounds good. Thanks, Sunil!

    - Furquan


    Thanks!
    Sunil


    Thanks,
    Furquan

    On Tue, Jun 21, 2022 at 9:48 PM Sunil V L <sunilvl@...> 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







    61 - 80 of 1845