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

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