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.
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>
>
>
>
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).
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>
>
>
>
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?
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.
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.
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).
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.
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.
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).
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.
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.
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).
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.
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?
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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).
On Mon, Jun 27, 2022 at 06:58:15PM +0530, Anup Patel wrote:
The rationale is that for M-mode the memory type is always defined by PMA(s) so if supervisor-mode software overrides memory type using Svpbmt then M-mode firmware will not see same contents as the supervisor-mode software.
I get the intent now. But we may not want to prohibit that.
We may want to document that the SBI will access this memory using the PMA attribute.
If the supervisor has accessed this same location using different cachability attribute than the PMA then a loss of coherence or unexpected memory ordering may occur and the invoking software should follow the rules and sequences defined in the Svpbmt specification to prevent the loss of coherence and memory ordering.
This does not place a restriction but warns against the issue and points to the right sequence if there is a legitimate reason to do it.
This should not be specific to this function but applicable to any function that the SBI defines with a memory operand and so could be stated more generally in the SBI specification.
On Mon, Jun 27, 2022 at 6:16 PM Ved Shanbhogue <ved@...> wrote:
On Mon, Jun 27, 2022 at 05:38:43PM +0530, Anup Patel wrote:
Also, a system might be partitioned into domains so a supervisor software running in a particular domain can only pass addresses accessible in that domain.
So domain is a new term which is not presently defined in the privileged specification or in the SBI specification.
The term "domain" is not used in the proposal since it is OpenSBI specific. My comment was mainly for Heinrich since he is already aware of OpenSBI domains.
In general, other M-mode firmwares might also implement some kind of system level partitioning.
I think I get what you may be stating here i.e., M-mode may configure/ reconfigure PMPs to restrict the physical addresses that are accessible to the supervisor-mode. Perhaps a future Smpu extension may add to this mix.
To avoid inventing a new term, we could reword #1 to state that the physical address must be accessible, as determined by the PMP and/or PMA rules, to the supervisor mode software invoking this SBI function.
To further restrict this perhaps say "accessible to read"? As we may not want execute-only to be allowed by this extension.
I mostly agree with your wording. Considering hypervisors and future memory protection ISA extensions, let's avoid using terms PMP.
For #1, we can say: The SBI implementation MUST check that the supervisor-mode software is allowed to read the specified physical address range on the calling HART.
For OpenSBI, we have domain regions so OpenSBI will check the address against regions of the domain assigned to calling HART.
Since "domain" is a concept that is not defined by either the privilege specification or the SBI specification we may want to avoid using that term (or add a definition).
The term "domain" was only in the context of OpenSBI. We should not use this term in the SBI specification.
This is more a requirement on the supervisor-mode software because we might have a system with Svpbmt so on such system supervisor-mode should not pass an address which is mapped as non-cacheable in the page table.
This is confusing since the description states that the parameter is a physical address but the later comment states its a virtual address and the memory type override using page-based memory type provided by the virtual memory system is allowed. Could we clarify if its a physical address - in which case only the coherence and cachability PMA should provide the memory type - or a virtual address in which case page-based memory type override is possible.
Further, a brief explanation about why cachability matters for this extension would be useful. Is this trying to imply some kind of early boot execution where caches may be placed in a special mode that allows operation when main memory is not available.
I agree the #2 requirement is not clear enough.
For #2, we can say: The supervisor-mode software MUST not override the memory type of specified physical address range using page-based memory types.
The rationale is that for M-mode the memory type is always defined by PMA(s) so if supervisor-mode software overrides memory type using Svpbmt then M-mode firmware will not see same contents as the supervisor-mode software.
On Mon, Jun 27, 2022 at 05:38:43PM +0530, Anup Patel wrote:
Also, a system might be partitioned into domains so a supervisor software running in a particular domain can only pass addresses accessible in that domain.
So domain is a new term which is not presently defined in the privileged specification or in the SBI specification.
I think I get what you may be stating here i.e., M-mode may configure/ reconfigure PMPs to restrict the physical addresses that are accessible to the supervisor-mode. Perhaps a future Smpu extension may add to this mix.
To avoid inventing a new term, we could reword #1 to state that the physical address must be accessible, as determined by the PMP and/or PMA rules, to the supervisor mode software invoking this SBI function.
To further restrict this perhaps say "accessible to read"? As we may not want execute-only to be allowed by this extension.
For OpenSBI, we have domain regions so OpenSBI will check the address against regions of the domain assigned to calling HART.
Since "domain" is a concept that is not defined by either the privilege specification or the SBI specification we may want to avoid using that term (or add a definition).
This is more a requirement on the supervisor-mode software because we might have a system with Svpbmt so on such system supervisor-mode should not pass an address which is mapped as non-cacheable in the page table.
This is confusing since the description states that the parameter is a physical address but the later comment states its a virtual address and the memory type override using page-based memory type provided by the virtual memory system is allowed. Could we clarify if its a physical address - in which case only the coherence and cachability PMA should provide the memory type - or a virtual address in which case page-based memory type override is possible.
Further, a brief explanation about why cachability matters for this extension would be useful. Is this trying to imply some kind of early boot execution where caches may be placed in a special mode that allows operation when main memory is not available.
On Mon, Jun 27, 2022 at 4:45 PM Heinrich Schuchardt <xypron.glpk@...> wrote:
On 6/27/22 10:46, Anup Patel wrote:
Hi All,
Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ...
The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing the legacy SBI v0.1 putchar() and getchar() calls. These legacy SBI v0.1 calls are now disabled by default in Linux and will be eventually deprecated. We need a replacement at least for the SBI v0.1 putchar() which is widely used for early prints in various OSes and Bootloaders. 2) The OS-A Platforms (or SEE) specification need to mandate a particular type of UART (8250, ns16550, or SiFive) as a standard way for boot-time early prints in supervisor-mode software. Using SBI debug console extension, the OS-A Platforms (or SEE) specifications don't need to mandate any type of UART. 3) The legacy SBI v0.1 putchar() only supports printing one character at a time. For some of the hypervisors (particularly KVM), SBI based early prints (i.e. earlycon=sbi) is slow because each SBI v0.1 putchar() trap will be forwarded to the KVM user-space (KVMTOOL or QEMU).
In short, the SBI debug console extension defines a standard way for boot-time early prints in supervisor-mode software.
The debug console extension defines a generic mechanism for boot-time early prints from supervisor-mode software which allows users to catch
Why should only S-mode and not HS-mode be allowed? I think the modes that are allowed to access this extension should be enumerated more clearly.
The term "supervisor-mode" over here means: * HS-mode or VS-mode on systems with H-extension * S-mode on systems without H-extension (Please see the introduction chapter of SBI specification) In fact, both HS-mode and VS-mode are actually supervisor-mode with different capabilities.
How are systems treated that only have M-mode and U-mode?
For systems with only M-mode and U-mode, there is no supervisor-mode hence there is no SBI on such systems. These are embedded-class systems which usually run some kind of RTOS.
boot-time issues in supervisor-mode software.
This extension replaces legacy console putchar (EID #0x01) extension and it is better in following ways: 1) It follows the new calling convention defined for SBI v1.0 (or higher). 2) It allows supervisor software to print multiple characters in a single SBI call.
If the underlying physical console has extra bits for error checking (or correction) then these extra bits should be handled by the SBI implementation.
struct sbiret sbi_debug_console_puts(unsigned long addr_div_by_4, unsigned long num_chars)
Print the string specified by the `addr_div_by_4` and `num_chars` parameters on the debug console. The `addr_div_by_4` parameter is the physical base address of the string right shifted by 2 whereas the `num_chars` parameter is the number of characters (or bytes) in the string.
The memory pointed the `addr_div_by_4` and `num_chars` parameters must be: 1) Accessible to supervisor-mode 2) Cacheable and writable memory
Accessibility by supervisor-mode is required due to security considerations: You should not be able to print out M-mode's secrets via S-mode software. This should be clearly stated.
The point#1 tries to say this. Also, a system might be partitioned into domains so a supervisor software running in a particular domain can only pass addresses accessible in that domain.
MUST an SBI implementation check this feature? Probably yes. How shall it be checked?
It's up to the SBI implementation how to check this feature.
As this is a security feature we should require:
The SBI MUST check that the full memory range is read-accessible by the caller.
For OpenSBI, we have domain regions so OpenSBI will check the address against regions of the domain assigned to calling HART. For KVM, the user-space tool (QEMU/KVMTOO) knows the guest physical address range of Guest RAM which can be used to validate the address.
The SBI is not meant to change the string and therefore needs no write access. There is no reason to require that the memory should be writable. The string could reside in NOR flash.
Caching may speed up the SBI code. But why should we require this specific memory region being cached?
This is more a requirement on the supervisor-mode software because we might have a system with Svpbmt so on such system supervisor-mode should not pass an address which is mapped as non-cacheable in the page table. We can certainly re-word this requirement to: "Cacheable and readable memory"
Here too we should make it clear if the SBI MUST or MAY check the property. I guess MAY is enough.
Best regards
Heinrich
One of the replies to your v1 patch requested to have the same capabilities as putchar(): just pass a single character in a register. Should a second FID be added?
It's pretty easy to print a single character using the proposed puts() call. For assembly source perspective, this will be just one extra instruction. Regards, Anup
Best regards
Heinrich
This is a blocking SBI call and will only return after printing all characters of the string.
Errors: SBI_SUCCESS - Characters printed successfully. SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_div_by_4` and `num_chars` parameters is either not accessible to supervisor-mode or does not point to cacheable and writable memory. SBI_ERR_FAILED - Failed to print characters due to I/O errors.
On Mon, Jun 27, 2022 at 4:45 PM Heinrich Schuchardt <xypron.glpk@...> wrote:
On 6/27/22 10:46, Anup Patel wrote:
Hi All,
Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ...
The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing the legacy SBI v0.1 putchar() and getchar() calls. These legacy SBI v0.1 calls are now disabled by default in Linux and will be eventually deprecated. We need a replacement at least for the SBI v0.1 putchar() which is widely used for early prints in various OSes and Bootloaders. 2) The OS-A Platforms (or SEE) specification need to mandate a particular type of UART (8250, ns16550, or SiFive) as a standard way for boot-time early prints in supervisor-mode software. Using SBI debug console extension, the OS-A Platforms (or SEE) specifications don't need to mandate any type of UART. 3) The legacy SBI v0.1 putchar() only supports printing one character at a time. For some of the hypervisors (particularly KVM), SBI based early prints (i.e. earlycon=sbi) is slow because each SBI v0.1 putchar() trap will be forwarded to the KVM user-space (KVMTOOL or QEMU).
In short, the SBI debug console extension defines a standard way for boot-time early prints in supervisor-mode software.
The debug console extension defines a generic mechanism for boot-time early prints from supervisor-mode software which allows users to catch
Why should only S-mode and not HS-mode be allowed? I think the modes that are allowed to access this extension should be enumerated more clearly.
The term "supervisor-mode" over here means: * HS-mode or VS-mode on systems with H-extension * S-mode on systems without H-extension (Please see the introduction chapter of SBI specification)
In fact, both HS-mode and VS-mode are actually supervisor-mode with different capabilities.
How are systems treated that only have M-mode and U-mode?
For systems with only M-mode and U-mode, there is no supervisor-mode hence there is no SBI on such systems. These are embedded-class systems which usually run some kind of RTOS.
boot-time issues in supervisor-mode software.
This extension replaces legacy console putchar (EID #0x01) extension and it is better in following ways: 1) It follows the new calling convention defined for SBI v1.0 (or higher). 2) It allows supervisor software to print multiple characters in a single SBI call.
If the underlying physical console has extra bits for error checking (or correction) then these extra bits should be handled by the SBI implementation.
struct sbiret sbi_debug_console_puts(unsigned long addr_div_by_4, unsigned long num_chars)
Print the string specified by the `addr_div_by_4` and `num_chars` parameters on the debug console. The `addr_div_by_4` parameter is the physical base address of the string right shifted by 2 whereas the `num_chars` parameter is the number of characters (or bytes) in the string.
The memory pointed the `addr_div_by_4` and `num_chars` parameters must be: 1) Accessible to supervisor-mode 2) Cacheable and writable memory
Accessibility by supervisor-mode is required due to security considerations: You should not be able to print out M-mode's secrets via S-mode software. This should be clearly stated.
The point#1 tries to say this.
Also, a system might be partitioned into domains so a supervisor software running in a particular domain can only pass addresses accessible in that domain.
MUST an SBI implementation check this feature? Probably yes. How shall it be checked?
It's up to the SBI implementation how to check this feature.
For OpenSBI, we have domain regions so OpenSBI will check the address against regions of the domain assigned to calling HART.
For KVM, the user-space tool (QEMU/KVMTOO) knows the guest physical address range of Guest RAM which can be used to validate the address.
The SBI is not meant to change the string and therefore needs no write access. There is no reason to require that the memory should be writable. The string could reside in NOR flash.
Caching may speed up the SBI code. But why should we require this specific memory region being cached?
This is more a requirement on the supervisor-mode software because we might have a system with Svpbmt so on such system supervisor-mode should not pass an address which is mapped as non-cacheable in the page table.
We can certainly re-word this requirement to: "Cacheable and readable memory"
One of the replies to your v1 patch requested to have the same capabilities as putchar(): just pass a single character in a register. Should a second FID be added?
It's pretty easy to print a single character using the proposed puts() call.
For assembly source perspective, this will be just one extra instruction.
Regards, Anup
Best regards
Heinrich
This is a blocking SBI call and will only return after printing all characters of the string.
Errors: SBI_SUCCESS - Characters printed successfully. SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_div_by_4` and `num_chars` parameters is either not accessible to supervisor-mode or does not point to cacheable and writable memory. SBI_ERR_FAILED - Failed to print characters due to I/O errors.
Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ...
The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing the legacy SBI v0.1 putchar() and getchar() calls. These legacy SBI v0.1 calls are now disabled by default in Linux and will be eventually deprecated. We need a replacement at least for the SBI v0.1 putchar() which is widely used for early prints in various OSes and Bootloaders. 2) The OS-A Platforms (or SEE) specification need to mandate a particular type of UART (8250, ns16550, or SiFive) as a standard way for boot-time early prints in supervisor-mode software. Using SBI debug console extension, the OS-A Platforms (or SEE) specifications don't need to mandate any type of UART. 3) The legacy SBI v0.1 putchar() only supports printing one character at a time. For some of the hypervisors (particularly KVM), SBI based early prints (i.e. earlycon=sbi) is slow because each SBI v0.1 putchar() trap will be forwarded to the KVM user-space (KVMTOOL or QEMU).
In short, the SBI debug console extension defines a standard way for boot-time early prints in supervisor-mode software.
The debug console extension defines a generic mechanism for boot-time early prints from supervisor-mode software which allows users to catch
Why should only S-mode and not HS-mode be allowed? I think the modes that are allowed to access this extension should be enumerated more clearly.
How are systems treated that only have M-mode and U-mode?
boot-time issues in supervisor-mode software.
This extension replaces legacy console putchar (EID #0x01) extension and it is better in following ways: 1) It follows the new calling convention defined for SBI v1.0 (or higher). 2) It allows supervisor software to print multiple characters in a single SBI call.
If the underlying physical console has extra bits for error checking (or correction) then these extra bits should be handled by the SBI implementation.
struct sbiret sbi_debug_console_puts(unsigned long addr_div_by_4, unsigned long num_chars)
Print the string specified by the `addr_div_by_4` and `num_chars` parameters on the debug console. The `addr_div_by_4` parameter is the physical base address of the string right shifted by 2 whereas the `num_chars` parameter is the number of characters (or bytes) in the string.
The memory pointed the `addr_div_by_4` and `num_chars` parameters must be: 1) Accessible to supervisor-mode 2) Cacheable and writable memory
Accessibility by supervisor-mode is required due to security considerations: You should not be able to print out M-mode's secrets via S-mode software. This should be clearly stated.
MUST an SBI implementation check this feature? Probably yes. How shall it be checked?
The SBI is not meant to change the string and therefore needs no write access. There is no reason to require that the memory should be writable. The string could reside in NOR flash.
Caching may speed up the SBI code. But why should we require this specific memory region being cached?
One of the replies to your v1 patch requested to have the same capabilities as putchar(): just pass a single character in a register. Should a second FID be added?
Best regards
Heinrich
This is a blocking SBI call and will only return after printing all characters of the string.
Errors: SBI_SUCCESS - Characters printed successfully. SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_div_by_4` and `num_chars` parameters is either not accessible to supervisor-mode or does not point to cacheable and writable memory. SBI_ERR_FAILED - Failed to print characters due to I/O errors.
Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ...
The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing the legacy SBI v0.1 putchar() and getchar() calls. These legacy SBI v0.1 calls are now disabled by default in Linux and will be eventually deprecated. We need a replacement at least for the SBI v0.1 putchar() which is widely used for early prints in various OSes and Bootloaders. 2) The OS-A Platforms (or SEE) specification need to mandate a particular type of UART (8250, ns16550, or SiFive) as a standard way for boot-time early prints in supervisor-mode software. Using SBI debug console extension, the OS-A Platforms (or SEE) specifications don't need to mandate any type of UART. 3) The legacy SBI v0.1 putchar() only supports printing one character at a time. For some of the hypervisors (particularly KVM), SBI based early prints (i.e. earlycon=sbi) is slow because each SBI v0.1 putchar() trap will be forwarded to the KVM user-space (KVMTOOL or QEMU).
In short, the SBI debug console extension defines a standard way for boot-time early prints in supervisor-mode software.
The debug console extension defines a generic mechanism for boot-time early prints from supervisor-mode software which allows users to catch boot-time issues in supervisor-mode software.
This extension replaces legacy console putchar (EID #0x01) extension and it is better in following ways: 1) It follows the new calling convention defined for SBI v1.0 (or higher). 2) It allows supervisor software to print multiple characters in a single SBI call.
If the underlying physical console has extra bits for error checking (or correction) then these extra bits should be handled by the SBI implementation.
struct sbiret sbi_debug_console_puts(unsigned long addr_div_by_4, unsigned long num_chars)
Print the string specified by the `addr_div_by_4` and `num_chars` parameters on the debug console. The `addr_div_by_4` parameter is the physical base address of the string right shifted by 2 whereas the `num_chars` parameter is the number of characters (or bytes) in the string.
The memory pointed the `addr_div_by_4` and `num_chars` parameters must be: 1) Accessible to supervisor-mode 2) Cacheable and writable memory
This is a blocking SBI call and will only return after printing all characters of the string.
Errors: SBI_SUCCESS - Characters printed successfully. SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_div_by_4` and `num_chars` parameters is either not accessible to supervisor-mode or does not point to cacheable and writable memory. SBI_ERR_FAILED - Failed to print characters due to I/O errors.
